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1.0 


Summary 


This report documents the work conducted under the NASA Advanced 
Transport Operating System task contract, Contract NAS 1-1 8027, Task 
Assignment 15. It describes the development of a system requirements 
definition for the flight control system of a commercial-type research aircraft of 
Langley Research Center’s Advanced Transport Operating System program, the 
Transport Systems Research Vehicle, also known as the NASA 515. 

The objective of this work was to develop a definition of the Transport Systems 
Research Vehicle flight control system requirements able to facilitate the 
research and development of alternate, more advanced software and possibly 
hardware architectures for modem transport aircraft flight control systems. 

The NASA 515 is a highly modified Boeing 737-100 aircraft designed 
specifically to investigate advanced navigation, guidance, control, and display 
concepts. In the experimental configuration, the aircraft is flown from a 
research flight deck (mounted in the aft cabin of the aircraft) whose entire flight 
control system is under software control. Therefore, alternate software 
implementations can readily be investigated. 

For the purposes of this report, the Transport Systems Research Vehicle flight 
control system is defined to be the baseline software for the NASA 515 research 
flight deck, including all navigation, guidance, and control functions, and 
primary pilot displays. At the beginning of this study, the system was built 
around two digital Norden PDP-1 1/70 computers, termed Norden #1 and 
Norden #2. Since that time, the system was modified and the Norden 
computers were replaced with DEC MicroVax computers. For this report the 
system will be described for the Norden computer configuration. Norden #1 is 
the host to a Sperry microprocessor display system which provides the Primary 
Flight, Navigation, and Engine Display formats; hence it is also refereed to as 
the Displays host computer. Norden #2 hosts the guidance, navigation, and 
control software; hence it is also referred to as the Flight Management/Flight 
Control host computer. 

The scope of the requirements definition contained herein is limited to a portion 
of the Flight Management/Flight Control computer functionality. Included is a 
discussion of the tasks required to increase the scope of the requirements 
definition and recommendations for follow-on research. 
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2.0 


INTRODUCTION 


There is a strong requirement for a new generation of avionics systems with a 
more integrated hardware and software structure. Future cockpits will 
incorporate a wide range of enhancements. Heavy application of artificial 
intelligence techniques can be expected to encompass the entire spectrum of 
crew station technologies: from data fusion to optimized display resource 
management, to real-time onboard maintenance and fault reporting, and even to 
the optimization of pilot physiological needs. There is a significant challenge to 
integrate symbolic and numeric computation in a real-time environment as well 
as to effectively allocate functions between man and avionics. In addition, 
advances in the development of distributed and parallel processing systems 
necessitate the careful allocation of processing tasks among the system’s 
computing resources in order to realize the increased system performance, 
reliability, and flexibility that these architectures offer. (References [1], [2], 
[3], [4].) 

In order to successfully address the function specification and allocation 
problem, both the application requirements and the system architecture should 
be considered. Consequently, an effective systems engineering analysis is 
required to first identify the system requirements. A good requirements 
analysis addresses a system's true requirements, that is, those essential features 
or capabilities that a system must possess in order to fulfill its purpose, 
regardless of how the system is implemented. Development of the best 
architecture for the application starts with a good essential requirements 
specification. 

The objective of this work was to analyze the NASA Transport Systems 
Research Vehicle (TSRV) flight control system (FCS) and develop a system 
specification that would offer high visibility of the essential system 
requirements in order to facilitate the future development of alternate, more 
advanced software and hardware architectures. 

Neither the original (i.e., essential) TSRV FCS requirements nor the evolution 
of the baseline software are well documented, thus the “essence” of the system 
was backed out of the existing implementation. The available documentation 
consists only of a somewhat cryptic software description document and a listing 
of the source code. Consequently, the specification produced is more 
influenced by the particular design preferences than would be a “top down” 
analysis for die development of an all new system. Furthermore, because the 
analysis was of an existing system, the scope of the requirements were limited 
to only those features actually implemented in the code. However, a good 
systems analysis should specify the (essential) requirements in such a way that 
they may be easily modified and/or extended to include new features. 

The systems analysis approach used was based on the Object Oriented Analysis 
(OOA) methodology developed by Boeing. In short, the Boeing OOA approach 
unifies traditional systems analysis methods of information modeling, process 
modeling (e.g., Yourdon -DeMarco Structured Analysis), and behavior 
modeling (e.g., Ward-Mellor Real-Time Extensions) into a single more 
powerful method which synergistically combines the strengths of all three 
methods. 
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A Computer Aided Software Engineering (CASE) tool is extremely useful for 
the OOA methodology. The Cadre Technologies Inc. teamwork tool was used 
on this project as it indirectly supports the Boeing OOA methodology and was 
readily available at Boeing. Because team work does not directly support the 
Boeing OOA approach, various conventions were developed to adapt 
teamwork to the OOA methodology. Furthermore, for this report, the 
teamwork data representing the TSRV FCS requirements analysis were 
reformatted into a single, unified, object-oriented specification. 

This report documents a partial set of TSRV requirements and includes: 

1 . A brief description of the existing baseline system 

2. A discussion of the systems analysis approach used, including 
an overview of OOA and a description of the typographical 
conventions manifest in the printed analysis 

3 . The requirements specification itself 

4. Recommendations for extending the scope of the analysis and 
for potential follow-on research acti vities 
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3.0 


Symbols and Abbreviations 


This section contains symbols and abbreviations used throughout this report, 
including those used in the requirements specification of Section 6. However, 
please note that it does not include “object identifiers.” These arc defined in the 
object class descriptions found in 6.1 (see also 6.4, Index of Identifiers). 


ADCEP 

AFCS 

AFD 

AGCS 

ATOPS 

BIU 

CADC 

CASE 

CRT 

CWS 

DAS 

DATAC 

DEC 

DEU 

DFD 

DMA 

DME 

DRll-AorB 

DU 

EIU 

Eiu/sru 

ENG 

ERD 

FAA 

FCS 

FFD 

FM/FC 

FPA 

GTA 

HSB 

IAS 

ILS 

MCP 

MLS 

MSP 

NASA 

NASA 515 

NCDU 

NAV 

Norden #1 
Norden #2 
OOA 
OCCM 
OCRD 


“Attribute / Derived attribute / Common domain / Event / 
Process” 

Automatic Flight Control System 
Aft Flight Deck 

Advanced Guidance and Control System 
Advanced Transport Operating System 
Bus Interface Unit 
Central Air Data Computer 
Computer Aided Software Engineering 
Cathode Ray Tube (display monitor) 

Control Wheel Steering 
Data Acquisition System 

Digital Autonomous Terminal Access Communication 

Digital Equipment Company 

Display Electronic Unit 

Data Flow Diagram 

Direct Memory Access 

Distance Measuring Equipment 

a general purpose DEC bus (UNIBUS) interface card; a 

type of DMA device 

Display Unit 

Effector Interface Unit 

Effector Interface Unit/Sensor Interface Unit 

Engine display format 

Entity-Relationship Diagram 

Federal Aviation Administration 

Flight Control System 

Forward Flight Deck 

Flight Management/Flight Control 

Flight Path Angle 

Ground Track Angle 

High Speed Bus 

Indicated Airspeed or Instrument Approach System 
Instrument Landing System 
Mode Control Panel (same as MSP) 

Microwave Landing System 
Mode Select Panel (same as MCP) 

National Aeronautics and Space Administration 

FAA designation for NASA’s TSRV airplane 

Navigation Control and Display Unit 

Navigation display format 

Host computer for TSRV AFD display system 

Host computer for TSRV AFD FM/FC functions 

Object Oriented Analysis 

Object Class Communication Model 

Object Class Relationship Diagram 
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OCRM 

Object Class Relationship Model 

PFD 

Primary Flight Display format 

SID 

Standard Instrument Departure 

SIU 

Sensor Interface Unit 

SS 

SID/STAR 

STAR 

Standard Terminal Arrival 

STD 

State Transition Diagram 

TSRV 

Transport System Research Vehicle 

WX 

Weather 



4.0 


System description 


The system of interest is the flight control system (FCS) for the research flight 
deck of NASA’s Transport System Research Vehicle (TSRV), a highly 
modified Boeing 737-100 commercial jet airplane, also referred to as the 
“NASA 515”. 

Hardware and software descriptions are included below only to provide a 
general overview of the system. Other references should be consulted for a 
more detailed understanding. 


4.1 Transport System Research Vehicle (TSRV) 

The TSRV is used as part of NASA’s Advanced Transport Operating System 
(ATOPS) program established to investigate advanced navigation, guidance, 
control, and display concepts. In the full-up test configuration it is flown from 
a second flight deck mounted in the cabin of the aircraft and referred to in this 
report as the Aft Flight Deck (AFD). The AFD contains the basic controls 
required to fly the airplane and uses the advanced controls and displays in a 
completely realistic environment. The AFD pilots have essentially complete 
control of the airpla ne, alt hough the AFD control authorities are limited and the 
forward flight deck (FFD) crew can take over control at any time. (References 
[5], [6].) 


4.2 Aft Flight Deck (AFD) Architectural Features 

The following description of AFD architectural features is based on References 
[5] and [7]. 

The AFD features programmable electronic Primary Flight Displays, Navigation 
Displays, and Engine Displays, a Navigation Control and Display Unit 
(NCDU), a glare-shield mounted Advanced Guidance and Control System 
(AGCS) Mode Select Panel (MSP), and Panel Mounted Controllers (PMCs) 
that take the place of conventional column and wheel controls. (Recently the 
PMCs were replaced with side arm controllers.) Also, a Data Acquisition 
System (DAS) provides real-time data recording and data display for inflight 
and postflight evaluation. 

Figure 4.1 is a simplified block diagram showing the arrangement of the 
principle components of the research system. The system is built around two 
Norden digital flight computers (militarized versions of the general purpose 
PDP-1 1/70 computer), designated Norden #1 and Norden #2. Both computers 
are interfaced to the AFD and an extensive array of sensors by a Digital 
Autonomous Terminal Access Communication (DATAC) system, a high-speed 
multitransmitter/receiver data bus. 

Norden #2, the Flight Management/Flight Controls (FM/FC) host computer, 
receives sensor information and switch/button settings from the Sensor 
Interface Unit (SIU) across the DATAC bus. Based on the modes selected on 
the MSP, and the flight path selected via the NCDU, it performs the flight 
management, guidance, navigation, and flight controls functions which generate 
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Figure 4.1 TSRV Aft Flight Deck Hardware Architecture 













commands that are issued to the control surfaces via the Effector Interface Unit 
(EIU) to direct the airplane in flight. In addition, the active and provisional 
guidance buffers as well as other data needed to generate displays are shipped to 
Norden #1 via a DR 11 -B interprocessor link. 

Norden #1, the Displays host computer, interprets input information from 
Norden #2 as well as from the sensors to create data blocks that are sent to a 
microprocessor-based Sperry Color Display System which provides the 
Primary Flight, Navigation, and Engine Display formats. 

The Sperry system communicates with the displays host through a Direct 
Memory Access (DMA) channel. The information from the host is processed 
by Intel 80186 microprocessors which generate data usable by Sperry display 
units (DUs) for the creation and positioning of display symbology. There are 
twelve individual pieces of hardware involved in the standard Sperry display 
configuration. Included are eight color display units (denoted PFD, NAV, or 
ENG in Figure 4.1), three display electronic units (DEUs), and one bus 
interface unit (BIU). Each DEU has four microprocessors containing programs 
which perform I/O functions and create data in formats acceptable to the DUs. 
Note that one of the microprocessors contained in DEU #2 is a weather (WX) 
radar processor which feeds weather radar to each DEU. 


4.3 Baseline Software 

For the purposes of this report, the TSRV FCS is defined by the “baseline” 
software for the TSRV research flight deck including all navigation, guidance, 
and control functions, and primary pilot displays. It is comprised of the 
software contained in the Displays host computer (Norden #1), the FM/FC host 
computer (Norden #2), and the Sperry Color Display System. 

The baseline software available for analysis on this project was a 1989 source 
code listing provided by NASA on a magnetic tape. This source code is best 
described by Reference [7], a software description document, also provided by 
NASA. The software described in Reference [7] is delivery 4.1 (D4.1) of the 
baseline FM/FC system which was released in July 1987. 

It should be noted that these resources represent various portions of the 
software current on different dates. Consequently, some inconsistencies were 
found during the analysis, hi these instances, the most logical and/or expedient 
resolution of the conflict was made; no attempt was made to document these 
conflicts or their resolution. 
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5.0 


Approach 


5.1 Systems Analysis 

This report addresses only part of the development of a complex, integrated 
system: the analysis and specification of its requirements. The role of “systems 
analysis” in the life-cycle of a system may be best understood in the proper 
context. Figure 5.1 shows one view of the evolution of a system, from the 
perception of a problem or objective to a fully operational solution. 

Initially, a problem generally exists as ideas about what the issues are as well as 
even preconceived notions of the solution; or at best, as a partial list of 
requirements. It is necessary to move from this nebulous condition to a more 
precise set of requirements, or better yet, a well-defined model of the 
requirements. This model should be a complete, consistent, and coherent 
specification of the essential requirements of the system. Analysis is the 
process which identifies the "essence" of a system. See Reference [8]. 

The concept of essence helps distinguish between the true requirements of a 
system and those things which are really implementation oriented and/or 
technology dependent. In the analysis stage, the specification of the system 
should not be influenced by past design solutions - “We’ve always done it that 
way” — or by current technology constraints such as processor speeds or 
memory limitations. It is important to clearly define what the system needs to 
do, not how it shall do it. 


Following the analysis phase is the design phase, where real-world constraints 
as well as design preferences are imposed upon the system’s essential 
requirements specification. The result is a technology dependent model of a 
solution to the problem. It represents one answer to the question, “How can the 
essence of this system be realized?” 

In the final phase of development, the design requirements are implemented in 
the form of hardware, software, etc. 

In the case of the TSRV FCS, the systems analysis process started from a 
specification of the system “as built”. Therefore, in a “reverse engineering” 
sense, the requirements were backed out of the existing implementation. 
Nevertheless, the goal was the same: to produce a specification of the essential 
system requirements. 
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Technology 

Constraints 
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Figure 5. 1 Systems Analysis in Context 



5.2 


Methodology Selection 


The analysis of the TSRV FCS was carried out using a Boeing-developed 
Object Oriented Analysis (OOA) methodology. See Reference [9]. The Boeing 
OOA method unifies traditional systems analysis methods of information 
modeling, process modeling (e.g., Yourdon-DeMarco Structured Analysis), 
and behavior modeling (e.g., Ward-Mellor Real-Time Extensions) into a single 
more powerful method which synergistically combines the strengths of all three 
methods. See References [8], [10], [11], and [12] for background information. 

OOA is an alternative to “structured analysis” as a requirements specification 
language. It unifies elements of information, behavior, and processing on an 
atomic level (object level), whereas structured analysis provides three 
hierarchical system level views which are not necessarily consistent and require 
parallel maintenance. OOA provides a method to rigorously define the 
requirements of any complex system in such a way that the analyst can readily 
identify any missing or contradictory requirements. The result is a complete, 
consistent, and simplified description of a system’s essential requirements. 

Furthermore, OOA provides a solid foundation for partitioning systems into 
“objects” and results in a system definition which allows a smooth transition 
into design. Object oriented specifications map very easily into object-oriented 
design and object-oriented programming (using languages such as Ada, 
Objective C, and Smalltalk), but also may be readily translated into other design 
schemes such as a standard hierarchical structured design. 

OOA’s partitioning methodology and design flexibility are a few of the features 
which make it particularly suited to the goal of defining alternate architectures 
for an existing complex system. 


5.3 OBJECT ORIENTED ANALYSIS (OOA) OVERVIEW 

OOA partitions a system into objects, or object classes. The goals of OOA are 
1) to assist in the “discovery” of the object classes in a system and the 
relationships between those object classes; and 2) to provide a mechanism to 
document those object classes so that they can be verified and later 
communicated to designers and programmers. The “products” of OOA and the 
relationships between them are depicted in Figure 5.2. The products are the 
deliverable results of applying OOA to a specific system. In other words, they 
are the graphic and textual models that are produced by the process of analysis. 

The products of OOA describe the system at two conceptual levels of 
detail: class level models and system level models. Class level models provide 
the detailed internal views of single object classes. System level models, on the 
other hand, describe the way object classes fit together to make the system as a 
whole. The system level models are not concerned with the internal details of 
the object classes. Likewise, the internal "schematic" of each object class must 
not concern itself with any other object class directly (i.e., knowledge of the 
internal workings of another object class is not allowed). These rules support 
the principle of information hiding. 
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5.3.1 


Class Level Models 


An object class can be thought of as a template that represents the generic form 
of all objects which belong to that class. Object classes can be described by the 
data they carry, the processes they perform, and the behavior they exhibit. 
Therefore, each object class template is comprised of three class level models: 
1) a Data Model; 2) a Process Model, and 3) a Behavior Model. In order for 
an object to be a member of a given class, it must conform to the class’ 
template: that is, it must be described by die prescribed data, it must do the 
prescribed work (processing), and it must exhibit the prescribed behavior. 


Data Models 

The data aspect of an object class is described textually by a set of Attributes. 
Each attribute represents a single meaningful fact that is pertinent to, and 
necessary for, all instances of that class. The set of attributes for an object class 
defines the information that is relevant for that class. 


Process Models 

The Process Model captures the functionality of an object class, that is, the 
activities or work performed by the objects in that class. The model defines the 
set of Processes that operate upon or manipulate objects within that class. 

A Process Model is described both graphically and textually. The graphical 
portion is in the form of the familiar dataflow diagram notation. A rigorous 
specification of the work performed by the processes is also necessary. The 
Structured Analysis “minispec” is a convenient mechanism for describing the 
details of a process. 


Behavior Models 

The behavior aspect of an object class is described by a finite state automaton. 
This can be thought of as a collection of States and Transitions which respond 
to certain Events. A state is a phase, stage, mode, or condition of being. The 
states for an object class are distinguished by ongoing processing, recognized 
events, and the responses to those events. An event is a circumstance, 
occurrence, or happening which may cause a change in the state of an object. A 
transition is a change from one state to another state due to a particular event 


5.3.2 System Level Models 

There are two system level models that show how the population of object 
classes in the system are interconnected. The Object Class Relationship Model 
(GCRM) and the Object Class Communication Model (OCCM) depict how the 
object classes interrelate and interact, respectively. 

The OCRM is represented by the Object Class Relationship Diagram (OCRD) 
(which resembles the Entity Relationship Diagram of traditional Information 
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Modeling methods). This model describes the existence relationships among 
object classes. A rough example of a relationship is, "every time there is an 
airport (object) there will be one or more runway (objects) associated with it" 

On the other hand, the OCCM depicts the dynamic communication which takes 
place between objects during the life of the system. A rough example is: "the 
human pilot (object) may — at some time -- send the following commands (in 
the form of data defined in the appropriate Data Model) to the autopilot (object): 
In other words, this model shows the sources and destinations of 
every event and dataflow that can pass between objects. In the case where the 
number of communications that take place in a system render a single 
communication diagram of the whole system unreadable, multiple 
communication diagrams can be developed, each focusing on a related subset of 
the communications in the system. 


5.3.3 External Object Classes 

It should be noted that a complete understanding of the internals (data, 
behavior, processing) of every object class is generally not required, and 
sometimes may not be possible. This gives rise to a special type of object class, 
an external object class. All that need be known about them is that they are the 
sources and/or destinations of named events and data for the system. 

The external object classes are identified in the analysis because they are 
significant in the overall understanding of the system. Later, these classes may 
be represented in the design phase by I/O interface routines. In the analysis 
phase, every object class must either be described by data, process, and 
behavior models, or be designated as an external object class. 


5.4 analysis Strategy 

A strategy serves the purpose of guiding the analyst toward the goal of 
completing the analysis, and different strategies may be appropriate in different 
situations. The analysis strategy used here was necessarily oriented toward the 
OOA methodology. The strategy was to develop the OOA models (see 5.3) of 
the system requirements using an information centered approach. 

With this strategy, the analyst focuses first on the information aspect of a 
system in order to discover as many of the object classes as possible. The 
result of this activity is a first approximation of the OCRM along with Data 
Models for each of the object classes found so far. 

Note that at this stage, those objects with little or no data (i.e., those which are 
more process and/or behavior intensive) have not necessarily been discovered: 
the list and definitions of the object classes are likely to be incomplete at this 
juncture. As subsequent phases of analysis (e.g., behavior and process 
modeling) are performed, new object classes may be discovered, or a few 
existing ones may be combined or split up. This is to be expected given a 
"bottom up" strategy of discovering object classes; the existence and 
completeness of an object class cannot truly and finally be validated until its 
Data, Process and Behavior Models are all defined. 
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Next, the analyst models the behavior aspect of the system by developing a 
Behavior Model for each object class. Additional behavior requirements not 
expressed by the Behavior Models for the known object classes may hint at the 
existence of hidden (i.e., as yet undiscovered) object classes that need to be 
exposed or at the need to re-partition some of the existing object classes. 

The next step involves modeling the processing aspect of the system by 
developing a Process Model for each object class. The approach is to examine 
every state and every transition defined in the Behavior Model for every object 
class and ask the question, “Is anything supposed to happen in this state or on 
this transition?” Processes are then created to represent the work required and 
those processes are coupled with the appropriate states or transitions. Again, 
additional processing requirements may expose new object classes. 

Finally, the OCCM of the system is built. In this strategy, the development of 
the communication model is a relatively mechanical process as no new 
information should be discovered. The task should be a simple matter of 
connecting the outputs of each object class to the appropriate inputs of the 
others. 

The description of this strategy implies a relatively step-by-step approach. In 
reality, it was a more iterative process. Nevertheless, it was a useful strategy, 
particularly for an analysis of an existing functional implementation where the 
existence and partitioning of objects was not obvious. 


5.5 CASE Tool 

A Computer Aided Software Engineering (CASE) tool is extremely useful for 
the OOA methodology. A CASE tool can be thought of as a database 
management application which includes graphics objects and freeform text 
entities in its database schema, includes editors for the manipulation of these, 
and provides appropriate navigation throughout the database. The Cadre 
Technologies Inc. teamwork family of tools (Reference [13]) was used as it 
was readily available at Boeing. 

The teamwork CASE tool family automates standard structured methodologies 
using interactive computer graphics and multi-user workstation power. Using 
teamwork the analyst can examine the system being developed from multiple 
viewpoints — all within one integrated environment that monitors the entire 
project’s progress, rigorously checks for errors and produces automatic 
documentation. Teamwork’s cheeking facilities provide automatic verification 
of the models by checking for completeness of the models, checking for 
consistency between models, and helping to find syntax errors. 

Team work analy sis tools help create descriptions and structured analysis of 
complex specifications. They allow description in both functional and object- 
oriented analysis. However, teamwork does not directly support an object 
oriented analysis approach. Consequently, various conventions were 
developed to adapt teamwork to the OOA methodology. Creative utilization of 
teamwork has allowed essential information not directly supported by 
teamwork to be recorded in the requirements specification (Section 6). Details 
regarding these conventions are described in 5.6. 
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Also, for the purposes of this report, a Boeing-developed team work database 
report writer was used to format the TSRV FCS requirements analysis into a 
single, unified, object-oriented specification (Section 6). 


5.6 Conventions 

When reviewing the requirements specification given in Section 6, it may be 
helpful to know beforehand some details regarding the conventions that have 
been followed. This sub-section documents the conventions present in the 
printed reports and diagrams that comprise the requirements specification. It 
does not attempt to explain all of the rationale behind various conventions, but 
rather is intended to be a concise resource for the reader of the specification. 
For this reason, notation that has been published and is generally known is not 
explained. Furthermore, familiarity with the concepts of OOA is assumed (see 
5.3), while knowledge of team work (see 5.5) is not. 

Teamwork did not directly support the Boeing OOA methodology. Although 
special application of the standard notation and conventions were defined by the 
tool developer to support Project Technology’s Real-Time Object Oriented 
Analysis (see Reference [12]), these conventions were lacking in various 
respects. For example, one naming convention that required object class names 
to contain parentheses and spaces made it difficult to navigate within the 
software and eliminated any chance of producing an error report. 
Consequently, various conventions were developed to adapt teamwork to the 
Boeing OOA methodology. Reference [14] contains additional background on 
some of the basic problems as well as solutions associated with using off-the- 
shelf CASE tools for Object Oriented Analysis. 

Any convention typically satisfies a number of demands simultaneously, though 
perhaps not all of them ideally. A compromise is often required among content, 
readability, ease of use, and teamwork's “happiness” with the idea. The 
conventions outlined below maximize content but avoid sabotaging the 
automation offered by teamwork (such as error reports, listings, on-line 
navigation among elements in the specification). At the same time, this 
supplementary-to-teamworfc information is captured in a rigorous fashion, 
amenable to mechanical (i.e., automated) syntax checking and cross- 
referencing. Some of the conventions are conventions required by teamwork. 
Others are Boeing-developed, and have enabled the recording of essential 
information in an OOA specification that is not directly supported — and 
therefore not expected — by team work. 

The following paragraphs are designed to allow the reader of the specification to 
extract important information at a glance. 

PLEASE NOTE: 

THE EXAMPLES PRESENTED HAVE BEEN TAKEN FROM THE 
REQUIREMENTS SPECIFICATION. HOWEVER, SOME HAVE 
BEEN MODIFIED TO BETTER ILLUSTRATE VARIOUS POINTS. 
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5.6.1 


General Conventions for All Names 
Some examples of various name conventions are: 


an object name: 
an object name: 
an object name: 
an attribute name: 
an attribute name: 
an attribute name: 
a derived attribute name: 
an event name: 
a process name: 
a relationship id: 
a relationship name: 


“FP-Flight_Plan” 

“WPT-Waypoint” 

“WFP— Waypoint_ona_Flight_Plan” 
“wfp- 1-OrdinalJPosition” 

“wfp- l-FUght_Plan_Name-RO 1 A” 

“wpt-l-Latitude-id02” 

“fp-2-Horizontal_Guidance_Possible” 

“tpg-3-Mode_Reversion” 

“Maintain_Selected_Altitude” 

“R05” 

“R05A-may_be_assigned_to” 


Words are generally capitalized and separated by an underscore (*_’); 
exceptions are allowed for small words such as “is”, “or”, etc. Relationship 
names are also an exception. 


Names always begin with a letter and contain only letters, numbers, 
underscores and dashes. 


The dash (*-’) is used only when explicitly required by these conventions; it is 
not used otherwise. 


A given name is generally made up of two or more parts, separated by the 
reserved dash character. One of these parts will be the basic name of the thing 
in question; that is, the ‘common’ word or phrase which is used in the analysis 
to uniquely identify the thing. The other parts, preceding and/or following this 
basic name, will embody useful or even necessary information. Teamwork, 
however, considers the name of the thing to be the full string of characters, and 
is thus unaffected by the augmentation. The full string of characters is 
sometimes referred to as the official name, or as simply the name of the object. 

Object names always begin with capital letters followed by a double dash. 
Attribute, derived attribute names and event names always begin with lower 
case letters, followed by “-2-”, and “-3-”, respectively. Relationship ids 
are always of the form ‘Rnn\ Relationship names always begin with the form 
‘RnnA’ or ‘RnnB’ followed by a single dash. 
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5.6.2 


Conventions for Object Classes 


Every object class has a name, a description, and the following models: a Data 
Model and/or a Behavior Model and/or a Process Model. An object class’ 
official name contains within it various flags and indicators. Its description is 
of a generic member of the class. The description is precise enough to enable a 
person to determine whether a candidate real-world object is - or is not - a 
member of the object class. It is a brief, imprecise English-language summary 
of the schematic template provided by the Data, Behavior and Process Models. 

Several conventions were followed regarding the representation of object class 
templates in the specification. These include some which relate to the building 
of a name for a class, the format of its description, primary identifier, and 
aliases, and its appearance on system level diagrams. These whole-object 
conventions are explained in detail in 5.6.2. Conventions for the various parts 
of an object class template (i.e., those associated with the parts of the class level 
models) are documented in 5.6.3, 5.6.4, and 5.6.5. 


Conventions for Object Class Names 

Refer also to 5.6.1, General Conventions for All Names. 

Some examples of object class names are: 

“FP— Flight_Plan” 

“WPT-Waypoint” 

“WFP— Waypoint_ona_Hight_Plan” 

The official object name consists of two parts: the object id and the basic name-, 
these are separated by a pair of dashes. (A double dash is required to ensure 
that the object name immediately precedes its attributes’ names in the case- 
insensitive alphabetic listing of teamwork names.) 

The object id is always present, always unique, generally mnemonic, and 
always entered in all capital letters. It is typically made from the first letters of 
the object’s name (“FP” for “Flight Plan”, “WFP” for “Waypoint on a Flight 
Plan”), though not always (“WPT” for “Waypoint”). This id is always two or 
more characters, and always begins with a letter. 

The basic name is always in the singular, naming a typical instance of the object 
class. 
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Conventional Format for Object Class Descriptions 


(regular abject class ) A real-world Navigational Aid <aka Nav Aid) is a 
radio broadcast device located on the surface of the earth designed to 
|i|Kiab|e an aircraft to deiermiue itsiadtadd itod longitude (so long as the 
aircraft is within the service range of the Nav Aid), Hie NAV AID 
object class represents the knowledge within the system that real 
1ft Navigational Aids exist in the real world; members of the NAV AID 
object class represent knowledge within the system of particular real- 
s' world nav aids. In other ^ds/|^is is NOT an external object 
the sy stem does NOT 

|||on-the-grourtd 'nav;! : iids:f^ ijsy^in icomm^ only: 

directly with aircraft on-board receivers and other sensors.) ' 

? The NAV AID object class is a subtype of tbe 'ATC^VFr object class. 

The value bfthe navaid-1 -Name is the official name designated by the 


The description is always present, indented from the left margin. 

The precise kind of object class being defined is given in italics within 
parentheses immediately prior to the body of the description. The following 
entries for object class kind may appear: regular object class; anonymous object 
class; external object class; external, anonymous object class; anonymous object 
class, no attributes; external, anonymous object class, no attributes. 

The description itself is free-form text of one or more paragraphs. 


Conventional Format for Object Class Primary Identifiers 


Primary Iden|ifierr;i|g|^ Uipi- (-Nami 


Any non-anonymous object class must have one or more identifiers. 

The chosen primary identifier is introduced with the key phrase “primary 
identifier”. When several attributes form the primary id, each attribute is 
separated by a plus sign (“+”), and should appear on a tine of its own; the last 
attribute may be followed by a period (“.”). Comment blocks, if present, are 
delineated with a begin and end asterisk (“*”). 

Non-primary identifiers are indicated via attribute naming conventions. Refer to 
5 . 6 . 3 . 
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Conventional Format for Object Class Aliases 


. Mas: Nav Aid, navaid; 


An object class may have aliases. If so, these are indicated using the format 
shown above. 


The Appearance of Object Classes on the OCRD 

Please note that the attribute list which appears inside the rectangle of a given 
object class on the Object Class Relationship Diagram (OCRD) is enclosed in a 
comment block — it has been entered manually, and teamwork has not checked 
for agreement between this list and the list which is part of the object’s 
definition. It may help to know this in case a subsequent change is required, or 
an inconsistency should arise. 


The Appearance of Object Classes on OCCDs 

Please note that just the object id appears within the object class rectangles on 
Object Class Communication Diagrams (OCCDs), to conserve diagram space. 
Also note that, by convention, a pair of asterisks following such an object id 
indicates that the context of the object class is not fully defined on that particular 
diagram; that is, there may be some data and/or events not shown on the 
diagram which this object class consumes or provides. 


5.6.3 Conventions for Attributes, Derived Attributes, Common 

Domains, Events, and Processes 

Several conventions were followed regarding the representation of attributes, 
derived attributes, events and processes in the analysis. These include some 
which relate to the building of a name for one, the format of its definition, and 
its appearance on diagrams. The notion of a common domain also aided in 
concise representation. 

Every attribute has a name and a definition. An attribute’s official name 
contains within it various flags and indicators (see Conventions for ADCEP 
Names). Its definition captures two things: the domain of values which the 
attribute can take on; and the precise meaning of those values for this attribute. 
The former is captured via a domain specification ; the latter via an English 
description (see Conventional Format for ADCEP Definitions). 

Common domains are created whenever two or more attributes share a common 
domain of values, due to an essential similarity (not a coincidence). This is 
done to follow the guideline, “Document each fact in just one place.” In these 
cases, the group of similar attributes simply reference the common domain 
definition by its name, rather than repeat the shared domain specification. Like 
attributes, every common domain has a name and a definition. 
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Attributes which reference other definitions are said to have nonprimitive 
definitions. Attributes come by nonprimitive definitions in three ways: by 
referencing common domains as described above, by being referential 
attributes, or by being compound attributes. An attribute which directly 
specifies a domain of values (i.e., which contains its own domain specification ) 
is said to have a primitive definition. 

A common domain usually has a primitive definition (i.e., usually contains its 
■; own domain specification). However, some common domains are compound 
domains, and these have nonprimitive definitions . Compound domains 
reference other common domains (never attributes). 

Derived attributes are identical to (regular) attributes except in an information 
modeling (data normalization) sense: they represent not stored data, but data 
derived from a process. (The process which derives a particular derived 
attribute may be explicitly defined for clarity or use in the Behavior Model, but 
is often left as an implied, always-available process. The term dataflow is not 
inappropriate.) Like attributes and common domains, every derived attribute 
has a name and a definition which consists of a description and a domain 
specification (which may be primitive, nonprimitive, or compound). 

Every event has a name and a description. The description of an event captures 
the precise meaning of the event when it occurs. (There is no domain 
specification, since an event just occurs in a moment in time and is then gone.) 

Every process has a name and a description (also known as a minispec). The 
description of a process captures what the process must accomplish, not how it 
will be accomplished: it is not algorithmic. (There is no domain specification 
since it makes no sense to speak of the values of the process itself.) 

Attributes, derived attributes, common domains, events and processes are quite 
similar in regards to the conventions followed for them. It is therefore useful to 
refer to “ ADCEPs ”. An ADCEP is “an attribute / derived attribute / common 
domain / event / process”, i.e., either an attribute or a derived attribute or a 
common domain or an event or a process. 


Conventions for ADCEP Names 


Refer also to 5.6.1, General Conventions for All Names. 


Some examples of ADCEP names are: 


an attribute name: 
an attribute name: 
an attribute name: 
an attribute name: 
an attribute name: 
a derived attribute name: 
an event name: 
a process name: 
a common domain name: 


“fp-l-Name” 

“wpt- l-Location_Description” 

“wpt- 1 -Longitude-id02” 

“wpt- 1 -Latitude-id02” 

“ wfp- 1 -Flight_Plan_N ame-RO 1 A” 

“fp-2-Horizontal_Guidance_Possible” 

“tpg-3-Mode_Reversion” 

“Maintain_Selected_Altitude” 

“domn-Airspeed” 
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The official ADCEP name consists of at least two parts: first (except for process 
names), the object id of the object class which is the source of the ADCEP in 
question (or, in the case of a common domain, the characters “domn” stand in 
the place of the object id); next, the basic name of the ADCEP; next, zero or 
more referential attribute tags; finally, zero or more identifier tags. All parts are 
separated by a single dash. 

It is a consequence of the above naming convention that a global dictionary 
printout (including both object classes and ADCEPs), alphabetized without 
regard to case, will list an object class’s attributes, derived attributes and events 
immediately after listing the object class. Also, all common domains will be 
defined in a contiguous block. This considerably improves the readability and 
usefulness of such a printout, and aids the analysis process. 

The object id (and “domn”) is always entered in all lower case letters. This 
simply improves readability by markedly distinguishing an ADCEP name from 
an object class name (entered in all capital letters). 

The basic name of the ADCEP signifies the meaning of the values in the domain 
of the ADCEP. (For events, it signifies the meaning of the event. For 
processes, it signifies the work accomplished by the process.) The meaning 
may be more precisely defined within the ADCEP’ s definition. 

Referential attributes will include one or more referential attribute tags. These 
tags will be of the form ‘RnnA’ or ‘RnnB’, and serve to (a) flag an attribute as 
referential; and (b) indicate which relationship(s) are referenced, that is, from 
which related object class the attribute was borrowed. (Refer to 5.6.6 for 
conventions for relationships.) 

For example, the reader immediately knows that the attribute “wfp-l-Flight_- 
Plan_Name-R01 A” is a referential attribute, because it has the ‘R’ tag “R01 A”. 
Specifically, the reader sees that relationship “R01” is referenced; and that the 
object class connected to line “R01A” is the object class from which the attribute 
comes. (“FP-FlightJPlan” in this case.) Therefore, the reader knows that the 
attribute “wfp-1 -FUght_Plan_Name-R01 A” is in an essential sense equivalent to 
one of the attributes from the object class “FP--Flight_Plan”. Exactly which 
attribute has been borrowed from the object class cannot be discerned from the 
attribute name itself; it is documented via the attribute’s definition (see 
Conventional Format for ADCEP Definitions). 

Attributes which form part of an identifier (a.k.a. key) will include one or more 
identifier tags. These tags name the identifier (primary, secondary, tertiary, ,..) 
of which an attribute is a part. The tag will be of the form ‘idnn’. For example, 
the attribute “ wpt- 1 -Latitude-id02” forms part of a secondary identifier for the 
“WPT--Waypoint” object class. Note, however, that primary identifiers are not 
always indicated in this way, because the analyst is required by teamwork to 
indicate a chosen primary identifier using a different method (see 
Conventional Format for Object Class Primary Identifiers in 5.6.2). 
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Conventional Format for ADCEP Definitions 

An ADCEP definition captures two things: the domain of values which the 
ADCEP can take on (the domain specification); and the meaning of those values 
for this ADCEP. (Events and processes have no domain specification.) While 
the meaning is often clear from the name of the ADCEP, a more precise 
description is usually helpful. The domain of values is described in essential 
(technology independent) terms; how these values might be stored in memory 
or on disk is of no concern in analysis. 

An ADCEP definition consists of a well-structured body of text. The six 
examples below illustrate some of the various kinds of definitions. They are 
followed by the details of the exact structure. 

1 . A nonprimitive definition of an attribute of an object class: 


airspdhmc-l>Selected_Afrspeed , 

; : (attribute) ^ ; 

TTtils"' : is ' which shall be maintained 
] domn- Airspeed. | 


2 . A primitive definition of an attribute of an object class: 


rw-l-Usable_Lengih 

(attribute) ~ 

^aiiblc : 

7T.:0.\ -i-U Type: V • , '7 

'■}. Range: from 250 to 30,000 feet; J; 

SI- Accuracy:" to 1 foot; 


3 . A primitive definition of a common domain : 


domn-Airspeed 

| ( common do main) - - ' - ' 

Type: Numeric; 

Range: from 45 to 750 feet per second; 

Accuracy: to 5 significant digits; t 
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4 . A nonprimitive definition of a common domain: 

domn-Latitude ' . . . 

| ; «. domn-Latitude JDegrces ,' 

. ,. : . . i '•■ ' ' : ' : ; , ; " £ ;; ;dkmm4UdwdcUBemispbere.7 ^ 


5. An event definition: 

1 hpg-3-Engagemeni_Criteria_Satisfied 

{broadcast event) ~ 7 . 

This event corresponds to a determination that the HPG can 
^^^K;ft : soccessfbllv th^ htaizorital coraponent|>fthe flight plan. 


6. A process definition: 


|fcapture_and JHold JSelected__Altitude 

§| (process) '•■; ;. 

This process generates avertical aixeleration steering command 
so as to smoothly change the actual altitude of the aircraft to 
match the pilot-selected altitude. 


Every definition begins with the AD CEP name in bold print on a line by itself. 
The precise kind of ADCEP being defined is given in italics within parentheses 
on the next line, indented 0.125 inches. The following may appear: 

• attribute; referential attribute; subtype indication; compound 
attribute; compound referential attribute; 

• derived attribute; compound derived attribute; 

• broadcast event; directed event; 

• process; 

• common domain; compound common domain. 
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An ADCEP definition usually has a description, indented 0.5 inches from the 
AD CEP name, and consisting of free-form English text. Except for events and 
processes, the description captures the precise meaning of the information 
recorded by the ADCEP. This description is commonly a brief, incomplete 
sentence like those of a normal dictionary entry, which assumes the reader 
mentally forms the sentence, “A [name] is [description].” Another common 
format is to begin the description with “This...”; the word refers to the ADCEP 
name. In the case of an event, the description records the precise meaning of 
the event’s occurrence. In the case of a process, the description records 
unambiguously what the process must accomplish without getting into how it 
might be implemented. Die description for an ADCEP may be omitted where 
obvious from the name. The ADCEP’s domain specification (if any) is 
enclosed in a rectangle indented from both margins about 1 inch. (Events and 
processes never have domain specifications; other ADCEPs must.) 

There are two kinds of domain specifications: primitive and nonprimitive. The 
ADCEP itself is said to have either a primitive or nonprimitive definition, 
accordingly. 


Nonprimitive ADCEP Definitions 

A nonprimitive definition references other ADCEPs in its domain specification. 
Generally, just a single ADCEP is referenced; occasionally, two or more may 
be referenced. 

Team work checks referenced ADCEPs when validating a nonprimitive 
definition. 

When two or more ADCEPs are referenced, this indicates that the ADCEP is 
actually composed of two or more meaningful parts, each with its own domain. 


i|idomn-Latitude ' 

W^&n&und co mmon 

domn-Latitude_Degrees. 

+ domn -Latitude JHemisphere, 





Reference to this ADCEP is, strictly speaking, a shorthand for reference to its 
parts (the true, atomic ADCEPs). Such an ADCEP is called a Compound 
ADCEP - specifically, a compound attribute, compound derived attribute, 
compound domain, and so on. 
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If a referenced ADCEP is an attribute of another object class (its name begins 
with an object id, not with “domn-”), as opposed to being a common domain, 
then the message is: 

this attribute is identical in meaning and domain to the referenced 
attribute; it is, in essence, the same attribute. 


wfp-i-Waypoint_Natne-R01B 

(referential attribute) ~ 

The id of the Waypoint which is on the named Flight _Plan by 
mean s of this WFP. t 

wpt-l-Name, 


Referential attributes are always defined in this way. 

If a referenced ADCEP is a common domain (its name begins with “domn-”), 
then the message is: 

this ADCEP has the same domain of values as the referenced 
common domain, but the precise meaning of those values for 
this ADCEP is documented in this definition's description. 


iirspdhihc-l-Selected]^ 

. (attribute) . : 1 \ 

• . \ This is the pilot-indicated airspeed which shall be maintained 
: ^SS ,; -^Mle’ die AirspeedLHol<llM6i&^ 

j domn - Airspeed. 


domn* Airspeed 

‘ • (common do main} • ' *' .' - ! > •' •••'>” : '-V- • A; " " 5:' 

Type: .....Numeric; >• 

Range: from 45 to 750 feet per second; 

Accuracy: to 3 significant digits; j 


Common domains are created whenever two or more ADCEPs share a 
common domain of values, due to an essential similarity (not a coincidence). 
This is done to follow die guideline, “Document each fact in just one place.” 
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Primitive ADCEP Definitions 

A primitive definition is one that does not reference other ADCEPs; its domain 
(if any) is explicitly stated via a domain specification. (Events and processes 
never have domain specifications; they are said to have primitive definitions.) 

The domain specification is not checked by teamwork, but does adhere to a 
rigorous syntax amenable to mechanical checking by auxiliary programs. 

The format of the domain specification varies, depending on the kind of domain 
being described: enumeration, subtype indication, string, numeric, or integer. 
However, all formats begin by indicating which of these five domain 
specifications follows (‘Type”). 

Enumerable domains are defined simply by listing the valid values. 


na vald-l-Type ' , 

{attribute) 

This indicates the class of the rav aid. 


Type: H 


Values: 

VOR, VOR-DME, TACAN, 


NDB, Localizer_Beacon; 


An attribute in a supertype which names the subtype object class is called a 
subtype indication, and its domain of valid values is, by definition, the object 
ids of the subtype object classes. 


/ Xsubtype indication) V ^ 

' The manner in which the aircraft will iriofe £r6m the previous 
WFP to this WFP. 


Type: Subtype Indication; 
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An ADCEP whose domain of valid values is strings of characters may be 
defined by a maximum size, minimum size, legal characters and/or format (if 
any). 


(attribute) •. 




mm 




ipili 

^String; 

Range: 

: fexactly 3 upper case1ettersr|||||| 


wpt- 1 -Local ionJDescri prion 

11 SBII short English description bf the location of the waypoint, 
:M#pica lly the name of a ijearby 




rw-l-Name .-^ih ' r ^ . 7 -H: i.: : ’ ' V . irk.-: 

:i (attribute ) - : : : y T i -• ^ 

•=: ’This is die official name of the Runway, whicH || determined by 
) its Magnetic 

^^^^ilelative 'to a runway parallel to the format 

Vts a sbirif of 1 jlQ2dip& egu^ J|^^pedc: : heading ! 

llltig§ left-hand runway and right-hand runway, hei^^pyely). If there 



Type:'*- 

^String; 


Rangell 

Ifcri i; to3:chamheliv^^^^i 

lllllll; 

Format:f 

Iph*- -.tz4 

w& 


!lllgi^®i!!ii“iSii« 


The description of a string ADCEP may have to include an English description 
of its required format in order to be precise. 
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Numeric ADCEPs are described by range and accuracy, as in the following 
examples. 


grre-l-UsabfejLeiigth 





Type; Numeric; ■mmrnm ..... 

Range: • from 250 to 30,000 WtttKM 
Accuracy: to ^ foot; Jj§ "' ' ' " ' 




domn-MagneticJVariation . •/ . v. : ^ : ’ 

(common domain) jjpyp . ^ • /: ' 

gllltlllthordl fidorr^ 

_■•••> • '.vv Type:; | : ■ .tfumstk; •. 

Range: it 

' ;: :.A,': ; :^y^ Accuracy: to 0,1 degrees; 


dottin- Airspeed 

p (common dot riadfC^ •' ■•’ 

' : Type: Numeric; 

||g®| 

•' :: 'V.x;- : .f Accuracy: to 3 significant digits 


g^omn- Altitude^Above^MeanjSe^I^yel^^^^vi^::^ 

ff^§Xcommon dom ain ) 


: : "f':;XX$ Type:. Hi Numeric; 

HitSf Range: f® from 1500 to 45,000 \ 

Accuracy: 
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Integer ADCEPs are described by range only. 


wfp-l-OrdinaMPositiononPlan 

(attribute) , \ f , , •• . | 

"S The sequential position (first, second, third, „.) of this "WFP on 

the na med Flight_Plan. - , 

Type: Integer; 

' - • Range: froml; . , - 


Note, however, that an ADCEP recorded to the nearest whole unit (such as rw- 
l-Usable_Length) is nor an integer ADCEP. It is still essentially numeric. 

NOTE: A pair of angle brackets (“o”) is used to denote “deliberately omitted” 
material. Such material was not uncovered during the analysis process. (Refer 
to Section 7 for a discussion of relevant recommendations.) 


domn-Magnetic_Variation 

(common domain) 

|||f | I An amount of v&adon ^ mpisii^'inagnetic 

III#' ' |P.v I Type: Numeric; 

llIMlll Range: . from -180 to +180 degrees; 

IPS' l||l; : Accuracy: to o degrees; 


The Appearance of Attributes on the OCRD 

The attributes of an object class are listed inside the object class rectangle on the 
OCRD, below a line of dashes. Note, however, that this list is enclosed in a 
comment block — it has been entered manually, and teamwork has not checked 
for agreement between this list and the list which is part of the object’s 
definition. It may help to know this in case a subsequent change is required, or 
an inconsistency should arise. 


5.6.4 Conventions for Behavior Model Diagrams 

Several conventions were followed regarding the representation of behavior via 
State Transition Diagrams (STDs). These include conventions which relate to 
the construction of state and transition labels and are explained in detail below. 
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Conventional Format for State Labels 


ARMED * 

w w r w< i w w? w /w . w. m: w. - w m" i r* yi> 

E. Display_S :ate 
E . Wat Ch_f o r_Pat h^Divgrgence | 
E» EvaluafcejEngageinentjCriteria 




The state name is given on line 1. Line 2 consists of a separator line to improve 
readability; note that this line is enclosed in a comment block which begins after 
the state name. Below this appear the enabled processes, in the usual “E.” 
notation. An id number for the state appears in the lower left comer. 


State names are in all capital letters. Words are separated with spaces rather 
than underscores (“_”)• 


Conventions for Transitions 

A transition is a change from one state to another state due to a particular event. 
The state from which a transition is drawn is referred to as the source state; the 
state to where it goes, the next state. The source state of a transition is said to 
“contain” that transition. Every transition has either an event block or a guard 
(or both), and may additionally have a response (ordered sequence of triggered 
processes and signalled events). 

Transition labels have been augmented in several ways in order to simplify 
otherwise busy STDs. A standard STD (i.e., a standard OOA STD) modified 
according to these conventions will generally have fewer transition lines and/or 
fewer state boxes. Please note, however, that the meaning of both diagrams is 
the same (i.e., the behavior specified is identical): the purpose of these 
conventions is to increase readability only. The transformation from an 
augmented to a standard version of a given STD is mechanical. 


afld-3-AltTtudej8^ 


a 


t . gs -2 -Engaged 


1 J 


The event block, when present, is always first. A slash (“/”) and a separator 
line follow the event block whenever a guard and/or response follow. The 
guard, when present, is always preceded and followed by a separator line, and 
always appears before the response (if any). The response, when present, 
always appears last, below a separator line. 
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Conventions relating to transition event blocks and guards arc described below. 
No special conventions were adopted for the response on a transition. 


Conventions for Transition Event Blocks 

An event block consists of a list of event names and/or boolean expressions. A 
mixture is allowed. Each item must be separated by the key word “.or.”. A 
transition which has a boolean expression in its event block is referred to as an 
evaluated transition. 

When more than one item is listed, the transition is taken to be a shorthand for a 
set of transitions (one for each item) which share the same source state, next 
state, guard and response. A step in the construction of the standard version of 
an SID is to replace such a transition with just that set. 

The event name carries the usual meaning: when an object of the class is in the 
source state, and the named event occurs, then the transition will be taken 
(unless the transition’s guard is false — see below). 

A boolean expression is a series of one or more relational expressions 
separated by “.or.” and/or “.and.”. Each relational expression compares an 
attribute or derived attribute of an object to that of another (or to a constant) via 
the usual operators:, “<”, “>”, “=”, etc. Relational expressions may be negated 
using “not.”, and may consist simply of an attribute or derived attribute name, 
so long as its domain is boolean. 

The boolean expression becoming true while the object is in the source state is 
treated as an event in the usual sense. Note well, however, the following 
subtlety. 

Upon entry into a state which contains one or more evaluated transitions, each 
of the boolean expressions must be evaluated (in any order), and the associated 
transition taken immediately if the guard evaluates to true; none of the enabled 
processes associated with the state shall begin until after all of these boolean 
expressions have been evaluated as false. This stipulation is extremely 
important, especially in light of the infinite speed with which an essential 
(technology independent) process is said to execute. 

It is possible to create non-deterministic state models using evaluated 
transitions; however, it is also possible to create non-deterministic state models 
using standard OOA state models in which states contain multiple processes that 
evaluate criteria and signal events (refer to the paragraph below). It is up to the 
analyst, as usual, to ensure the correctness of the state model, which may or 
may not mean ensuring that the model is deterministic. 

A step in the construction of the standard version of an STD is to relegate the 
evaluation of a boolean expression in an event block to a specially-created 
process which signals one of two specially-created events (one event for 
“[boolean expression] true,” another for “[boolean expression] false.” A 
specially-created “temporary evaluation” state for each original state containing 
one or more evaluated transitions would enable all the original state’s specially- 
created processes, and would contain two transitions: one going into the 
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original state (for the “false” event), and one going into the next state of the 
original evaluated transition. (The response on the former being null; the 
response on the latter being the response of the original.) All transitions going 
into the original state would be redirected to the specially-created state. 

When one of the events occurs, or when one of the boolean expressions 
evaluates to true, it is said that an event in the event block has occurred. 


Conventions for Transition Guards 

A guard consists of a single boolean expression. A transition containing a 
guard is referred to as a guarded event transition, and cannot be taken unless the 
guard evaluates to true at the time an event in the event block occurs. If the 
guard evaluates to false, then the transition is not taken: the event in the event 
block is ignored. It is permissable for a guard to appear on a transition which 
has no event block. However, in this case, the guard is treated as ah event 
block consisting of single boolean expression. See Conventions for 
Transition Event Blocks for more on boolean expressions. 

As with evaluated transitions, the evaluation of the boolean expression can be 
relegated to a specially-created process which signals one of two specially- 
created events. Any guarded event transition would be modified by removing 
its original response and changing its next state destination to a specially-created 
“temporary evaluation” state which would enable the specially-created process, 
and would contain two transitions: one going back into the source state of the 
original guarded event transition, with null response (for the “false” event), and 
one going ahead into the original next state of the original guarded event 
transition, with response equal to that of the original. 


5.6.5 Conventions for Process Model Diagrams 

Part of the specification of a process may be to generate particular events when 
certain conditions are met. In this case, the process is shown to produce the 
event by means of a dotted arrow notation. Other than this, no special 
conventions were adopted for Process Model diagrams. 


5.6.6 Conventions for Relationships 

Several conventions were followed regarding the representation of relationships 
in the analysis. These include some which relate to the building of a name for a 
relationship, its definition, and its appearance on diagrams. 

Throughout the discussion of these conventions, please refer to Figure 5.3, 
which shows an annotated example from the OCRD. 
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Relationship Relationship 

Name and Name and 

Multiplicity . . Multiplicity 


Relationship Relationship 


Every relationship has an id, two names, two statements of multiplicity, and a 
definition. A relationship’s id is a simple identifier used by teamwork. Each 
name is formed by prefixing a relationship name id to the basic name of the 
relationship itself. Each name (as well as each statement of multiplicity) is 
defined from the viewpoint of one of the object classes, so that one can refer to 
the subject and object of the name (or statement of multiplicity), in the 
grammatical sense of these words. 

Each basic name signifies the meaning behind an association between members 
of the two object classes from the viewpoint of a generic member of the subject 
object class. Each statement of multiplicity captures the number of objects from 
the object object class that may be associated with a single object from the 
subject object class. The relationship’s definition documents the precise details 
of a relationship, expanding on the meanings signified by the relationship as it 
appears on the Object Class Relationship Diagram (OCRD). 


Conventions for Relationship Names 
Refer also to 5.6.1, General Conventions for All Names. 


Some examples of relationship names are: 


“RO 1 A-may_be_on” 

“RO 1 B-consists_of ’ 

“R04A-centers_on” 

“R04B-may_be_the_center_of’ 

The official relationship name consists of two parts: the relationship name id 
and the basic name. These are separated by a single dash. 

The relationship name id is always present; it uniquely identifies one of the two 
names for the relationship. It is always formed by appending ‘A’ or ‘B’ to the 
relationship id. Each relationship is assigned a unique id of the form ‘Rnn’ 
(e.g., R01 , R02, R23, R46), referred to as the relationship id. This id is the 
only way teamwork will refer to the relationship. Keep this in mind when 
reading teamwork-generated reports and listings. Teamwork uses this id (and 
only this id) to alphabetize. 

The basic name of the relationship is always a verb or verb phrase. It signifies 
the meaning of an association between members of the two object classes from 
the viewpoint of a generic member of the subject object class. The precise 
meaning attached to the association is documented in the relationship definition 
(see Conventions for Relationship Definitions). Which object class is 
die subject of the verb phrase, and which is the object, is obvious from the 
physical placement of the relationship name on the OCRD, but cannot be 
discerned from the name alone (see The Appearance of Relationships on 
the OCRD). These verb phrases might use the word “may” to underscore the 
conditionality of the relationship, though not always. 
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Conventions for Statements of Multiplicity 


Some examples of statements of multiplicity are: 

“0 <= N” 

“3 <= N” 

“0 <= N <= 2” 


The statement of multiplicity follows a straight-forward, teamwork-imposed 
syntax. It documents half of what is conventionally called the ‘multiplicity of 
the relationship’: the minimum and maximum number of objects in a class (the 
object object class) which might be associated, at any one time, with an object 
of the subject object class, defined from the viewpoint of a generic member of 
the subject object class. The other half of the ‘multiplicity of the relationship’ is 
documented in the other statement of multiplicity , in which the two object 
classes have reversed grammatical roles. For an example, refer to Rendering 
an English Definition From OCRD Relationships. 


Conventions for Relationship Definitions 

A textual plain-English relationship definition need not be given unless the 
definition will illuminate subtle aspects of reality or policy not obvious from the 
relationship as documented on the Object Class Relationship Diagram (OCRD). 


The Appearance of Relationships on the OCRD 

As shown in Figure 5.3, most aspects of a relationship are documented on the 
OCRD; only the definition is absent. (The definition serves to clarify the terse, 
somewhat artificial statements appearing on the OCRD.) 

Recall that a relationship name is either a verb or a verb phrase. As shown in 
the figure, each name appears next to the object class which is the object of the 
verb phrase (in the grammatical sense), as is customary when using two names. 
For example, the relationship name which is derived from the viewpoint of a 
“WPT— Waypoint” is placed next to the object class rectangle for “FP~ 
Flight_Plan”; the former object class is the subject object class, the latter the 
object object class. 

The statement of multiplicity which appears next to each relationship name 
follows a self-evident, teamwork-imposed syntax. The statement of 
multiplicity appears adjacent to the object object class, and is defined from the 
viewpoint of a generic member of the subject object class. 

As shown, the relationship name and statement of multiplicity appear together, 
generally on a single line. The relationship name is enclosed in a comment 
block; teamwork does not perform any checking of this name. However, 
teamwork does inspect and expect statements of multiplicity. 
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The relationship id appears inside the relationship diamond. This id is the only 
way teamwork will refer to the relationship. Keep this in mind when reading 
teamwork-generated reports and listings. Teamwork uses this id (and only 
this id) to alphabetize. 


Rendering an English Definition From OCRD Relationships 

It generally helps the reader of an OCRD gain an understanding of the meaning 
of a relationship by reading all parts together in two sentences, as follows. 

1. Read the name of one of the object classes; an object class is 
always named in the singular. 

2. Read the relationship name (verb phrase) which is next to the 
other object class. 

3. Read the statement of multiplicity which follows the name, 
translating it into English. 

4. Read the name of the other object class, treating it as the object 
of the verb (in die grammatical sense), switching to the plural 
form for one-to-many and many-to-many relationships. 

5. Repeat this process from the other direction (starting with the 
other object class). 

The relationship depicted in Figure 5.3 may thus be read as follows: 

“A Flight Plan consists of 3 or more Waypoints .” 

“A Waypoint mav be on zero or more Fli ght Plans .” 
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6.0 


Requirements Specification 


This section contains the actual requirements specification for the TSRV flight 
control system (see Section 4 for a system description). Although strictly 
speaking it is self-contained, any specification is best understood in the proper 
context A key to a good understanding of the specification is an understanding 
of the typographical conventions used in it. Refer to 5.6. Of course, it is also 
imperative to understand the concepts of Object Oriented Analysis (OOA). 
Refer to 5.2 and 5.3 

The scope of the requirements definition contained herein is limited to the Flight 
Management/Flight Control computer functionality. (Future analysis would 
surely expand this “system boundary” in order to fully specify the TSRV flight 
control system. Section 7 contains recommendations along these lines.) Within 
the scope of the system analyzed, some requirements were identified but not 
thoroughly analyzed. In this analysis, such requirements were captured by 
identifying special placeholder object classes. 

Such an object class is termed a “pseudo external object class”: treated as 
external until such time as this aspect of the system can be analyzed further. 
For the interim, this object class provides a source and sink for closely related 
events and data: those known to be required by objects already defined in the 
analysis. Further analysis may reveal that this single placeholder must become 
several object classes. Also, several of these pseudo external object classes 
might be split and joined. 

The requirements specification is divided into four sub-sections. 6.1 specifies 
the object classes alphabetically by defining the class level models for each 
object class. 6.2 contains definitions for “Common Domains,” which are 
referred to within object class specifications when defining the domain of valid 
values of particular data (see 5.6). 6.3 contains system level models: an Object 
Class Relationship Model and an Object Class Communication Model. Finally, 
6.4 consists of an Index of Identifiers, which will aid in determining where an 
identifier is defined or referenced. 

NOTE: it may be useful to consult the system level models to formulate a 
reading order of the class level specifications given alphabetically in 6.1. 


6 . l Class Level Models 

This sub-section contains the complete specification of each object class, in 
alphabetical order. The requirements contained in the class level models are laid 
out in a format geared for maximum readability, although 5.3 and 5.6 may be 
useful in understanding the various products of OOA and the conventions used 
for the various pieces of a specification, respectively. The layout of these 
specifications and the explicit correspondence between the layout and the class 
level products of OOA are described below. 

Each object class is defined within its own paragraph, 6,l,n (where *n’ is a 
number): its Data Model, Behavior Model, and Process Model are documented. 
The title to paragraph 6.1.n consists of the official name of the object class. 
Immediately following this title is the object class description. Following the 
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description, are Summary and Definitions. If the object class has a 
Behavior and/or Process Model, the Behavior Model Diagram and/or Process 
Model Diagram appear after Definitions. 

Summary consists of a summary of the object class: all attributes, derived 
attributes, events and processes are listed here without being defined. Also 
included is the primary identifier of the object class, along with any aliases by 
which the class is known. If the object class has a Behavior or Process Model, 
such is indicated. 

Definitions contains all of the textual definitions relevant to the object class. 
It defines the attributes, derived attributes, events and processes (in this order). 
Thus the Data Model is completely contained in Definitions (and is 
summarized in Summary), while just the textual definitions associated with the 
Behavior Model and Process Model appear. 

The Behavior Model Diagram and Process Model Diagram depict the Behavior 
Model and Process Model, in the forms of a State Transition Diagram (STD) 
and a Data Flow Diagram (DFD), respectively. These diagrams document 
essential information; they are not mere summaries of information present 
elsewhere in the specification. 


However, every item referenced on these diagrams is defined textually in 
Definitions of the source object class specification. With respect to the STD, 
signalled events, triggered processes and enabled processes are listed in 
Summary, and defined in Definitions. Consumed events are defined in the 
source object class specification, as are attributes and derived attributes 
appearing in boolean expressions. The meaning of a state is taken to be self- 
evident from (and identical to) the context given in the STD; a textual 
description is not given. With respect to the DFD, signalled events, processes, 
and “outflow” attributes and derived attributes are listed in Summary, and 
defined in Definitions. Consumed (“inflow”) attributes and derived attributes 
are defined in the source object class specification. 
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6.1.1 AAMC— AFD_AFCS_Mode_ControlIer 

0 anonymous object class, no attributes ) The AAMC, when enabled, controls the 
highest modes of the Automatic Flight Control System (AFCS). It takes input 
from the AFD as well as from the various subordinate mode-controller objects 
(for automatic mode reversion). 


Primary Identifier: 
Behavior Model: 
Event: 

Event: 

Event: 

Event: 

Event: 

Event: 


Summary 


none 

present 

aamc-3-Disengage_Auto_Modes 

aamc-3-Disengage_Default_Mode 

aamc-3-Disengage_VCWS 

aamc-3-Engage_Auto_Modes 

aamc-3-Engage_Default_Mode 

aamc-3-Engage_VCWS 


Definitions 


aamc-3-Disengage_Auto_Modes 

(< directed event) 

This event corresponds to a command from the AAMC to the 
AUTOMC. 

aamc-3-Disengage_DefauIt_Mode 

(i directed event) 

This event corresponds to a command from the AAMC to the DEFMC. 
aamc-3-Disengage_VCWS 

( directed event) 

This event corresponds to a command from the AAMC to the VCWS. 
aamc-3-Engage_Auto_Modes 

(directed event) 

This event corresponds to a command from the AAMC to the 
AUTOMC. 

aamc-3-Engage_Default_Mode 

(directed event) 

This event corresponds to a command from the AAMC to the DEFMC. 
aamc-3-Engage_VCWS 

(directed event) 

This event corresponds to a command from the AAMC to the VCWS. 
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AFD__Enabled / 


3-Engage_Default_f 

lode 


afcse-3-AFD_Disabled / 


S . a amc-3-D i a enga ge_Aut o_Mode ! 

r 




S. aaioc-3-Diaengage_Autq^Modes 
a. aatnc“3-Engage_VCWS 
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6.1.2 


ACWS— Attitude_HoId_Control_Wheel_Steering_Mode_Controller 

( anonymous object class) The Attitude JHk)ld_Control_Wheel_Steering__Mode_- 
Controller, while engaged, maintains the attitude of the aircraft by issuing 
commands to the Effector_Controller. The ACWS allows the AFD_Crew to 
change the attitude-being-maintained by responding to wheel/column inputs (or 
equivalent control inputs) while engaged. 


Primary Identifier: 
Alias: 

Behavior Model: 
Process Model: 
Attribute: 

Attribute: 

Attribute: 

Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Process: 

Process: 


Summary 


none 

ACWS Mode Controller 

present 

present 

acws-l-Selected_Bank_Angle 

acws- 1 -Selected_Pitch_Angle 

acws- 1 -Selected_Yaw_Angle 

acws-2-Attitude_Hold_Engaged 

acws-2-Commanded_Bank_Angle 

acws-2-Commanded_Pitch_Angle 

acws-2-Commanded_Yaw_Angle 

Set_Selected_Ammde_to_Actual 

Maintain_Attitude_of_Aircraft 


Definitions 


acws-l-Selected_Bank_Angle 

(attribute) 

domn-Bank_Angle. 


acws -l-SelectedPitch_ Angle 

(attribute) 

I domn-Pitch__ Angle. 


acws-l-Se!ected_Yaw_AngIe 

(attribute) 

domn- Y aw_Angle. 


acws-2*Attitude_Hold_Engaged 

(derived attribute) 

“True” while the ACWS is engaged (i.e., controlling the aircraft so as to 
maint ain an attitude); “false” when disengaged. 

I domn-Boolean. 1 


acws-2-Commanded_Bank_Angle 

(derived attribute ) 

I domn-Bank_Angle. 
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acws-2-Commanded_Pitch_AngIe 

(< derived, attrib ute ) 

domn-Pitch_Angle. 


acws-2-Commanded_Yaw_AngIe 

(i derived attrib ute} 

I domn-Yaw_Angle. ” 


Set_SeIected_Attitude_to_ActuaI 

(process) 

This process makes the selected attitude (pitch, bank, yaw) of the 
aircraft equal to the instantaneous actual attitude. 

Maintain_Attitude_of_Aircraft 

(process) 

This process commands the Effector_Controller to maintain the selected 
attitude (pitch, bank, yaw) of the aircraft, while at the same time 
allowing die Aft Flight Deck Crew to modify this selected attitude via 
control inputs. 
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Attltude_Hold_ 

ControLWhee7_SteerIng_ 

Mode_Controtler 

BEHAVIOR MODEL 



Figure 6.2 Behavior Model Diagram for ACWS 
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Figure 6.3 Process Model Diagram for ACWS 
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6.1.3 AFCSE— AFCS_EnabIer 

( anonymous object class, no attributes) The AFCSE enables and disables the 
Automatic Flight Control System (AFCS), taking input only from the Forward 
Flight Deck Crew. 


Primary Identifier: 
Behavior Model: 
Event: 

Event: 

Event: 

Event: 


Summary 

none 

present 

afcse-3-AFDJDisabled 
afc se- 3 - AFD_Enabled 
afc se-3- FFD _Di sabled 
afcse-3-FFD_Enabled 


Definitions 


afcse-3-AFD_Disabled 

(broadcast event) 

This event is signaled at the moment the AFCSE disables the AFD. 
afcse-3-AFD_Enabled 

(broadcast event) 

This event is signaled at the moment the AFCSE enables the AFD. 
afcse-3-FFD_Disabled 

(broadcast event) 

This event is signaled at the moment the AFCSE disables the FFD. 
afcse-3-FFD_Enabled 

(broadcast event) 

This event is signaled at the moment the AFCSE enables the FFD. 
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Figure 6.4 Behavior Model Diagram for AFCSE 
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6.1.4 


AFD— Aft_Flight_Deck_Crew 

(external, anonymous object class, no attributes) The Aft_Flight_Deck_Crew consists 
of the research pilots who fly the aircaft in the aft flight deck. 


Summary 


Primary Identifier: 

none 

Derived Attribute: 

afd-2-Autothrottle_Engaged 

Derived Attribute: 

afd-2-Column_Position 

Derived Attribute: 

afd-2-Designated_Default_Mode 

Derived Attribute: 

afd-2-Rudder_Pedal_Position 

Derived Attribute: 

afd-2-Wheel_Position 

Event: 

afd-3-Airspeed_Decrement_Request 

Event: 

afd-3-Airspeed_Hold_Mode_Deselect 

Event: 

afd-3-Airspeed_Hold_Mode_Request 

Event: 

afd-3-Airspeed_Increment_Request 

Event: 

afd-3-Aldtude_Decrement_Request 

Event: 

afd-3-Altitude_Hold_Mode_Deselect 

Event: 

afd-3-Altitude_Hold_Mode_Request 

Event: 

afd-3-Altitude_Increment_Request 

Event: 

afd-3-Attitude_Hold_Deselect 

Event: 

afd-3-Auto_Modes_Deselect 

Event: 

afd-3-Auto_Modes_Request 

Event: 

afd-3-Autothrottle_Deselect 

Event: 

afd-3-Default_Mode_Request 

Event: 

afd-3-Flight_Path_Angle_Decrement_Request 

Event: 

afd-3-Flight_Path_Angle_Hold_Mode_Deselect 

Event: 

afd-3-Flight_Path_Angle_Hold_Mode_Request 

Event: 

afd-3-Flight_Path_Angle_Increment_Request 

Event: 

afd-3-Ground_Track_Angle_Decrement_Request 

Event: 

afd-3-Ground_Track_Angle_Hold_Mode_Deselect 

Event: 

afd-3-Ground_Track_Angle_Hold_Mode_Request 

Event: 

afd-3-Ground_Track_Angle_Increment_Request 

Event: 

afd-3-Horizontal_Guidance_Deselect 

Event: 

afd-3-Horizontal_Guidance_Request 

Event: 

afd-3-Time_Guidance_Deselect 

Event: 

afd-3-Time_Guidance_Request 

Event: 

afd-3-Velocity_Vector_Hold_Deselect 

Event: 

afd-3-Velocity_Vector_Hold_Request 

Event: 

afd-3-Vertical_Guidance_De select 

Event: 

afd-3-Vertical_Guidance_Request 


Definitions 


afd-2-Autothrottle_Engaged 

(derived attribute) 

“True” when the AFD has engaged the autothrottle. Note: this derived 
attribute has been placed in the AFD object class until such time as the 
syste m can be analyzed further. 

I domn-Boolean. 
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afd-2-Co!umn_Position 

(derived attribute) 

The c ontrol input which indicates the desired Pitch Angle of the aircraft. 
I domn-Column_Positidn. I 


afd-2-Designated_Defau!t_Mode 

(derived attribute) 

The mode to which the AFCS should default when a higher mode 
reverts, or when die AFD selects “Default Mode"; the abbreviations 
stand for “Attitude Hold Control Wheel Steering” and “Manual 
Electr ic”, resp. 

Type: Enumeration; 

Values: ACWS, ManEl; 


afd-2-Rudder_Pedal_Position 

(derived attribute) 

The c ontrol input which indicates the desired Yaw Angle of the aircraft 
domn-Rudder_Pedal_Position. 


af d -2- W h ee!_Position 

(derived attribute) 

The c ontrol input which indicates the desired Bank Angle of th e aircraft. 
I domn-Wheel_Position. 


afd-3-Airspeed_Decrement_Request 

(broadcast event) 

This event corresponds to a request to decrease the maintained or 
preselected airspeed. 


afd-3-Airspeed_Hold_ModeJDeselect 

(broadcast event) 

This event corresponds to a request to release control of the aircraft's 
airspeed; i.e., a request to disengage the AIRSPDHMC. 

afd-3-Airspeed_Ho!d_Mode_Request 

(broadcast event) 

This event corresponds to a request to hold the current or preselected 
airspeed; i.e., a request to engage the AIRSPDHMC. 

afd-3-Airspeed_IncrementJRequest 

(broadcast event) 

This event corresponds to a request to increase the maintained or 
preselected airspeed. 
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afd-3-Altitude_Decrement_Request 

(broadcast event) 

This event corresponds to a request to decrease the maintained or 
preselected altitude. 


afd-3-Altitude_Hold_Mode_DeseIect 

(broadcast event) 

This event corresponds to a request to release control of the aircraft's 
altitude; i.e., a request to disengage the ALTHMC. 

afd-3-Altitude_Ho3d_Mode_Request 

(broadcast event) 

This event corresponds to a request to hold the current or preselected 
altitude; i.e., a request to engage the ALTHMC. 


afd-3-Altitude_Increment_Request 

(broadcast event) 

This event corresponds to a request to increase the maintained or 
preselected altitude. 


afd-3-Attitude_Hold_Deselect 

(broadcast event) 


This event corresponds to a request to disengage the “Attitude Hold with 
Control Wheel Steering (CWS)” mode; i.e., a request to disengage the 
ACWS Mode Controller. 


afd-3-Auto_Modes_Deselect 

(broadcast event) 

This event corresponds to a request to disable the automatic flight modes 
(the “Auto” Modes). 


afd-3-AutoJModes_Reqiiest 

(broadcast event) 

This event corresponds to a request to enable the automatic flight modes 
(the “Auto” Modes). 

afd-3-Autothrottle_Deselect 

(broadcast event) 

This event corresponds to a request to release automatic control of the 
throttle. 
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afd-3-Default_Mode_Request 

(broadcast event) 

This event corresponds to a request to engage the default mode of 
autopilot control, which might be the ACWS mode or the Manual 
Electric mode. 

afd-3-Flight_Path_Angle_Decrement_Request 

(broadcast event) 

This event corresponds to a request to decrease the maintained or 
preselected flight path angle. 

afd-3-FIight_Path_Angle_Hold_Mode_Deselect 

(broadcast event) 

This event corresponds to a request to disengage the FPAHMC. 

afd-3-Flight_Path_Angle_Hold_Mode_Request 

(broadcast event) 

This event corresponds to a request to hold the current or preselected 
flight path angle. 

afd-3-FIightJPath_Angle_Increment_Request 

(broadcast event) 

This event corresponds to a request to increase the maintained or 
preselected flight path angle. 

afd-3-Ground_Track_Angle_Decrement_Request 

(broadcast event) 

This event corresponds to a request to decrease the maintained or 
preselected ground track angle. 

afd-3-Ground_Track_Angle_Hold_Mode_Dese!ect 

(broadcast event) 

This event corresponds to a request to release control of the aircraft's 
ground track angle; i.e., a request to disengage the GTAHMC. 

afd-3-Ground_Track_Angle_Hold_Mode_Request 

(broadcast event) 

This event corresponds to a request to hold the current or preselected 
ground track angle; i.e., a request to engage the GTAHMC. 

afd-3-Ground_Track_Angle_Increment_Request 

(broadcast event) 

This event corresponds to a request to increase the maintained or 
preselected ground track angle. 
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afd-3-Horizontal_Guidance_Deselect 

(broadcast event) 

This event corresponds to a request to disengage the “Horizontal Path 
Guidance” mode; i.e., a request to disengage the Horizontal Path Guide. 

afd-3-Horizontal_Guidance_Request 

(broadcast event) 

This event corresponds to a request to engage the “Horizontal Path 
Guidance” mode; i.e., a request to engage the Horizontal Path Guide. 

afd-3-Time_Guidance_Deselect 

(broadcast event) 

This event corresponds to a request to disengage the “Time Path 
Guidance” mode; i.e., a request to disengage the Time Path Guide. 


afd-3-Time_Guidance_Request 

(broadcast event) 

This event corresponds to a request to engage the “Time Path Guidance” 
mode; i.e., a request to engage the Time Path Guide. 

afd-3-VeIocity_Vector_HoId_Deselect 

(broadcast event) 

This event corresponds to a request to disengage the “Velecity Vector 
Hold with Control Wheel Steering (CWS)” mode; i.e., a request to 
disengage the VCWS Mode Controller. 


afd-3-Velocity_Vector_Hold_Request 

(broadcast event) 

This event corresponds to a request to engage the “Velocity Vector Hold 
with Control Wheel Steering (CWS)” mode; i.e., a request to engage the 
VCWS Mode Controller. 

afd-3-Vertica!_Guidance_Deselect 

(broadcast event) 

This event corresponds to a request to disengage the “Vertical Path 
Guidance” mode; i.e., a request to disengage the Vertical Path Guide. 

afd-3-Vertical_Guidance_Request 

(broadcast event) 

This event corresponds to a request to engage the “Vertical Path 
Guidance” mode; i.e., a request to engage the Vertical Path Guide. 



6.1.5 AIL— Aileron 

{external, anonymous object class, no attributes ) The Aileron is one of the 
aerodynamic control effectors used to control the motion of the aircraft. 


Summary 

Primary Identifier: none 

Derived Attribute: ail-2-Current_Position 


Definitions 


ail-2-CurrentJPosition 

{derived attribute) 

This i s the current sensed position of the aileron. 
domn-Aileron_Position. 
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6.1.6 


AIRSPDHMC— Airspeed_Hold_Mode_Controller 

(< anonymous object class) The Airspeed_Hold_Mode_Controller, when engaged, 
commands the Effector.Controller to capture and maintain a pilot-selected 
airspeed. 

Summary 


Primary Identifier: 
Behavior Model: 
Process Model: 
Attribute: 

Derived Attribute: 
Process: 

Process: 

Process: 

Process: 

Process: 

Process: 

Process: 


none 

present 

present 

airspdhmc* 1 -Selected_Airspeed 

airspdhmc-2-Commanded_Airspeed 

Display_Actual_Airspeed 

Display_Selected_Airspeed 

Set_Selected_Airspeed_to_Actual 

Increment_Selected_Airspeed 

Decrement J>elected_Airspeed 

Display_State 

Capture_and_Hold_Selected_Airspeed 


Definitions 

airspdhmc-l»Selected_Airspeed 

(attribute) 

This is the pilot-indicated airspeed which shall be maintained while the 
Airsp eed_Hold_Mode_Controller is engaged. 

domn-Airspeed. 


airspdhmc-2-Commanded_Airspeed 

(derived attribute) 

This i s the commanded airspeed which shall be attained. 
I domn-Airspeed. 


Display _Actual_Airspeed 

(process) 

This process display s the Actual_Airspeed of the aircraft. 

Display_Selected_Airspeed 

(process) 

This process displays the Selected.Airspeed. 

Set_Selected_Airspeed_to_ Actual 

(process) 

This process makes the Selected. Airspeed attribute equal to the 
instantaneous Aetual.Airspeed. 
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Increment_SeIected_Airspeed 

(process) 

This process increases the current Selected_Airspeed by 5 knots. 
Decrement_SeIected_Airspeed 

(process) 

This process decreases the current Selected_Airspeed by 5 knots. 

DisplayJState 

(process) 

This process makes visible the current state of this object. (The 
implementation of this process may display a message on a CRT, or it 
may light different colored lamps.) 

Capture_and_HoId_Selected_Airspeed 

(process) 

v . This process commands the S urface_Con trailer to change the Actual 
Airspeed of the aircraft to match the Selected Airspeed. 
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Figure 6.5 Behavior Model Diagram for AIRSPDHMC 
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Figure 6.6 Process Model Diagram for AIRSPDHMC 
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6.1.7 ALTHMC— Altitude_Hold_Mode_Controller 

( anonymous object class) The Altitude_Hold_Mode_Con trailer, when engaged, 
generates steering commands so as to capture and hold a pilot-selected altitude. 
It issues a vertical acceleration steering command. 


Summary 


Primary Identifier: 

none 

Behavior Model: 

present 

Process Model: 

present 

Attribute: 

althmc- l-Selected_Altitude 

Derived Attribute: 

althmc-2-AltitudeJDifference 

Derived Attribute: 

althmc-2-Commanded_Vertical_Acceleration 

Event: 

althmc-3-Disengagement_Criteria_Triggered 

Event: 

althmc-3-Engagement_Criteria_Satisfied 

Process: 

Display_Actual_Altitude 

Process: 

Display_Selected_Altitude 

Process: 

Set_Selected_Altitude_to_Actual 

Process: 

Increment_Selected_Altitude 

Process: 

Decrement_Selected_Altitude 

Process: 

Capture_and_Hold_Selected_Altitude 

Process: 

Watch_Altitude_Difference 

Process: 

Display_State 


Definitions 

althmc-l-Seiected 

Altitude 

(attribute) 



This is the pilot-indicated altitude which shall be captured and held when 
the Al ritude_Hold_Mode_Controller is en gaged. 

I domn-Altitude_Above_Mean_Sea_Level. 


a!thmc-2-Altitude_Difference 

(derived attribute) 

This is arithmetic difference between the actual and the select a ltitudes. 
I domn-Altitude_Above_Mean_Sea_Level. 


althmc-2-Commanded_Vertical_Acceleration 

(< derived attribute) 

This is the commanded vertical acceleration of the aircraft which shall be 
attained 

| domn-Acceleration. 


aIthmc-3-Disengagement_Criteria_Triggered 

(broadcast event) 

This event corresponds to a determination that the Altitude Hold Mode 
Controller must disengage, that is, release control of the aircraft. 
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aIthmc-3-Engagement_Criteria_Satisfied 

(broadcast event) 

This event corresponds to a determination that the Altitude Hold Mode 
Controller can successfully capture the Selected Altitude. 

Display_ActuaI_Altitude 

(process) 

This process displays the Actual_Altitude of the aircraft. 

Display_Selected_AItitude 

(process) 

This process displays the Selected_Altitude of the aircraft. 
Set_Selected_Altitude_to_Actual 

(process) 

This process makes the Selected_Altitude attribute equal to the 
instantaneous Actual_Altitude. 

Increment_Selected_Altitude 

(process) 

This process increases the current Selected_Altitude by 50 feet. 


Decrement_Selected_Altitude 

(process) 

This process decreases the current Selected_Altitude by 50 feet. 
Capture_and_Hold_Selected_Altitude 

(process) 

This process generates a vertical acceleration steering command so as to 
smoothly change the actual altitude of the aircraft to match the pilot- 
selected altitude. 


Watch_Altitude_Difference 

(process) 

This process monitors the difference between the Actual_ Altitude of the 
aircraft and the Selected_Altitude. At the moment the difference is small 
compared to the vertical speed of the aircraft, this process signals the 
Engagement_Criteria_Satisfied event, so that the selected altitude may 
be captured. At the moment the difference exceeds the maximum 
expected during altitude hold, the Disengagement_Criteria_Triggered 
event is signalled by this process, so that the Capture_and_Hold process 
can be disengaged. 

Display_State 

(process) 

This process makes visible the current state of this object. (The 
implementation of this process may display a message on a CRT, or it 
may light different colored lamps.) 
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Figure 6.8 Process Model Diagram for ALTHMC 
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6.1.8 


AP-Airport 

(regular object class ) An AirPort is an air traffic control area from which aircraft 
take off and at which aircraft land. That is, the definition here follows the 
ordinary usage. 


Primary Identifier: 
Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 


Summary 

ap-l-Name 

ap- 1 - Automd_Trml_Info_S vc_Radio_Freq 

ap- 1 -Clearance_Radio_Frequency 

ap- 1 -Ground_Control_Radio_Frequency 

ap-l-Is_it_Usable 

ap-l-Name 

ap- 1 -Reference_Point JLatitude 
ap- 1 -Reference_Point_Longitude 
ap- 1 -Tower_Radio_Frequency 


Definitions 


ap-l-Automd_Trml_Info_Svc_Radio_Freq 

(attribute) 

This item is useful for the human pilot, and is otherwise unused in this 
analy sis. 

domn-Radio_Frequency. 


ap-l-Clearance_Radio_Frequency 

(attribute) 

This item is useful for the human pilot, and is otherwise unused in this 
analy sis. 

domn-RadioJFrequency. 


ap- 1- G roun d_Con trol JRa di o_Fr equen cy 

(attribute) 

This item is useful for the human pilot, and is otherwise unused in this 
analy sis. 

domn-Radio_Frequency. 


ap-l-Is_it_UsabIe 

(attribute) 

This indicates whether the aircraft is allowed to land at the Airport under 
normal conditions. This item determines how the airport is displayed to 
the hu man pilot. 

Type: Enumeration; 

Values: Operational, Display_Qnly; 
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ap-l-Name 

{attribute) 

The o fficial id of the airport; not its common English name. 
Type: String; 

Range: exactly 4 upper case letters; 


ap-l-Reference_Point_Latitude 

{attribute) 

This is the latitude of the official “location” of the airport as defined by a 
single point on the Earth’s surface. 

I domn-Latitude. ~ 1 


ap-l-Reference_PointJLongitude 

{attribute) 


This is the longitude of the official “location” of the airport as defined by 


a sing 


le point on the Earth’s surface. 


domn-Longitude. 


ap-l-Tower_RadioJFrequency 

{attribute) 

This item is useful for the human pilot, and is otherwise unused in this 
analysis; : 

domn*Radio_Frequency. 
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6.1.9 


ATCWAR— ATC_Waypoint_onan_Airway_Route 

(regular object class) A ATC_WaypQint_onan_Airway_Route arises out of the 
association of a particular ATC_Named_Waypint (ATCWPT) with a particular 
Published Airway Route (PAR). It captures die information relevant to such an 
association. (The same ATCWPT on a different PAR may be assigned different 
data values.) 

“ATC_Waypoint_onan_Airway_Route” is a somewhat artificial term created for 
the sake of clarity in this analysis; in general usage, the term “ATC-Named 
Waypoint” may refer to both ATCWPTs and ATCWARs (where the meaning is 
clear from context). For that matter, the term “Waypoint” may refer to an 
ATCWPT or even an ATCWAR. 


Summary 

Primary Identifier: atcwar- 1 -Route_Name-R 1 OB 

+ atcwar- 1 -Wpt_N ame-R 1 OA. 

Attribute: atcwar- 1 -Route_Name-R 1 OB 

Attribute: atcwar- 1 -Wpt_Name-R10A 


Definitions 

atcwar-l-Route_Name-R10B 

(compound referential attribute ) 

The id of the Published Airway Route which the named ATC Named 
Wayp oint is on by means of this ATCWAR. 

par-l-Type 
+ par- 1 -Number. 


atcwar-l-Wpt_Name-R10A 

(referential attribute) 

The id of the ATC Named Waypoint which is on the named Published 
Airwa y Route by means of this ATCWAR. 

I atcwpt- l-Waypoint_Name-R17. 
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6.1.10 ATCWPT— ATC_Named_Waypoint 

( regular object class) An ATC_Named_Waypoint is a Waypoint which is officially 
recognized, and which is documented on air navigation charts. Being an 
official entity, an ATCWPT is not modifiable by a pilot. 


Primary Identifier: 

Attribute: 

Attribute: 


Summary 

atcwpt- l-Waypoint_Name-R17 

atcwpt-l-Type-R18 

atcwpt- l-Waypoint_Name-R17 


Definitions 


atcwpt-l-Type-R18 

{subtype indic ation ) 


Type: 

Subtype Indication; 

Objects: 

NAVAID, ISN; 


atcwpt-l-Waypoint_Name-R17 

( referential att ribute ) 

wpt-l-Name. 
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6.1.11 AUTOLAND— Automatic_Landing_ControlIer 

( external , anonymous object class, no attributes) This object class is a “pseudo 
external object class": treated as external until such time as this aspect of the 
system can be analyzed further. For the interim, this object class provides a 
source and sink for closely related events and data: those associated with 
landing and known to be required by objects already defined in this analysis. 
Further analysis may reveal that this single placeholder must become several 
object classes. Also, several of these pseudo external object classes might be 
split and joined. 


Summary 

Primary Identifier: none 

Derived Attribute: autoland-2-Glide_Slope_Engaged 

Derived Attribute: autoland-2-Localizers_Engaged 


Definitions 


autoland -2- GlideSlopeEngaged 

(derived attrib ute} 

I domn-Boolean. 


autoland-2-Localizers_Engaged 

(derived attrib ute) 

I domn-Boolean. 
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6.1.12 AUTOMC--Auto _Modes_ControHer 

{anonymous object class, no attributes) The AUTOMC enables the engagement of the 
various “automatic flight modes”. 


Summary 

Primary Identifier: none 

Behavior Model: present 

Derived Attribute: automc-2-Auto_Modes_Engaged 


Definitions 

automc-2-Auto_Modes_Engaged 

{derived attribute) 

“True” while the AAMC has authorized the engagement of any of the 
automatic flight modes; “false" when that authorization has been 
retrac ted. 

I domn-Boolean. 
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6.1.13 CR-CompanyJRoute 

(regular object class) A Company_Route is a pilot- or company-defined Flight_- 
Plan which is used frequently. Company_Routes aid the pilot by eliminating 
the need to “manually” enter the same sequence of Waypoints each time a 
frequently travelled path is desired. “Company Route” is a generally recognized 
term of the aviation community. Note: it is thought that Company_Routes 
generally begin and end at the edges of airport air traffic control areas. 


Summary 

Primary Identifier: cr- 1 -Name. 

Attribute: cr-l-Name 


Definitions 


cr-l-Name 

(attribute) 

Type: String; 
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6.1.14 CWFP~Constrained_Waypoint_ona_Flight_Plan 

(regular object class) A Constrained_Waypoint_ona_Flight_Plan is a special kind 
of WFP used primarily for SID and STAR waypoints. A WFP of this type 
allows more than the usual, simple specification of an altitude or planned time 
of arrival; rather, altitude and airspeed constraints on a flight leg are recorded. 

Summary 

cwfp-1 -Flight JPlan_Name-R02 
+ cwfp-l-Waypoint_Name-R02 

cwfj^l-Airspeed_Constraint_for_Wpt_Acq 
cwfp-l-Airspeed_Value_for_Wpt_Acq 
cwfp- l-Altitude_Constraint_at_Wpt 
cwfj>- l-Altitude_Value_at_Wpt 
cwfp-1 -Flight_Plan_Name- 1 -R02 
cwfp- 1 -W aypoint JSfame- 1 -R02 


Definitions 

cwfp-l-Airspeed_Constraint_for_Wpt_Acq 

(attribute) 

This constraint must be continually met during the whole of waypoint 
acqui sition. It applies to die cwfp-l-Airspeed_Value_for_Wpt _Acq. 

domn-Leg_Constraint. 


Primary Identifier: 


Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 


cwfp-1 -AirspeedVal ue_fo.r_Wp.t_ A c q 

(attribute) 

This defines the airspeed for the aircraft for the whole of waypoint 
acquisition. The attribute cwfp-l-Airspeed_Constraint_for_Wpt_Acq 
define s what the aircraft must do with this value. 

domn-Airspeed. 


cwfp-l-Altitude_Constraint_at_Wpt 

(attribute) 

This constraint must be met just by the time the aircraft is actually at the 
wayp oint It applies to the cwfp- l-Altitude_Value_at_Wpt. 

| domn-Point_Constraint. 


cwfp-l-AItitude_Value_at_Wpt 

(attribute) 


This defines the altitude for the aircraft just when actually at the 
waypoint. The attribute cwfp-l-Altitude_Constraint_at_Wpt defines 


whattl 


lie aircraft must do with this value. 


domn-Altitude_Above_Mean_Sea_Level. 
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cwfp-l-Flight_Plan_Name-l-R02 

(referential att ribute ) 

wfp- 1 -Flight_Plan_Name-R01 A. 


cwfp-l-Waypoint_Name-l-R02 

(referential att ribute ) 

wfp- 1 -Waypoint_Name-R01B 




6.1.15 


DA— Direct_Acquisition 

p regular object class) A Direct_Acquisition is a Waypoint_ona_Flight_Plan which 
is acquired (flown to) directly (roughly, in a straight line) from the preceeding 
WFP. 


Summary 

Primary Identifier: da-l-Flight_Plan_Name-R02 

+ da-l-Waypoint_Name-R02 


Attribute: 

Attribute: 

Derived Attribute: 


da- 1 -Flight_Plan_Name-R02 

da-l-Waypoint_Name-R02 

da-2-Distance_to_Tangent 


Definitions 


da-l-Flight_Plan_Name-R02 

(i referential att ribute ) 

wfp- 1 -Flight_Plan_Name-RO 1 A. 


da-l-Waypoint_Name-R02 

(referential att ribute ) 

wfp- 1 -W aypoint_N ame-RO 1 B. 


da-2-Distance_to_Tangent 

(derived attribute) 

Indicates the distance to the tangent point of the standard rate turn arc 
which is used to transition smoothly from the current leg to the next. 

Type: Numeric; 

Range: from 0 to o nautical miles; 
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6.1.16 DEFMC— Default JVIode_ControIler 

( anonymous object class, no attributes) The Default Mode Controller controls the 
engagement and disengagement of the designated “default mode” (which is 
chosen by the AFD). 


Primary Identifier: 
Behavior Model: 
Event: 

Event: 

Event: 

Event: 

Event: 


Summary 


none 

present 

defmc-3-Disengage_ACWS 

definc-3-Disengage_MANEL 

defmc-3-Engage_ACWS 

defmc-3-Engage_MANEL 

defmc-3-Mode_Reversion 


Definitions 


defmc-3-Disengage_ACWS 

( broadcast event) 

This event corresponds to a determination that the ACWS must 
disengage. 


defmc-3»Disengage_MANEL 

(broadcast event) 

This event corresponds to a determination that the MANEL must 
disengage. 


defmc-3-Engage_ACWS 

(broadcast event) 

This event corresponds to a determination that the ACWS should 
engage. 

defmc-3-Engage_MANEL 

(broadcast event) 

This event corresponds to a determination that the MANEL should 
engage. 

defmc-3>Mode_Reversion 

(broadcast event) 

This event corresponds to the self-disengagement of the DEFMC. The 
event is generated to let other objects in die system react as they will. 
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DtfauKJMocte_Controil«r 
BEHAVIOR MODEL 



*fd~2-De»ignat4d__Default_Mode 


afd-'2~Designated_Default_Mode I— "HAN EL" 
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6.1.17 DME A A-DME_Arc_Acquisition 

(regular object class) A DMEAA is a Waypoint_ona_Flight_Plan which is acquired 
(flown to) via an arc (with the aid of DME) from the preceeding WFP. The 
proceeding WFP is known as the “inbound waypoint” of the dme arc, while this 
WFP is known as the “outbound waypoint”. This is why the method of 
acquiring this WFP is said to be via a dme arc: that is the path in space between 
the two WFPs. 


Primary Identifier: 


Attribute: 

Attribute: 

Attribute: 

Attribute: 


Summary 

dmeaa- 1 -Flight_Plan_Name-R03 
+ dmeaa- l-Waypoint_Name-R03 

dmeaa-l-Direction_of_Tum 
dmeaa- 1 -Flight JPlan_Name-R03 
dmeaa- 1 -Tum_Center_Wpt_N ame-R04 
dmeaa- 1 -Waypoint_Name-R03 


Definitions 


dmeaa - 1 -Dir ection_of_Turn 

(attribute) 


This attribute partially defines the arc acquisition path; without it, two 
different paths (together forming a circle about the Tum_Center) would 
be am biguously defined. 


Type: Enumeration; 

Values: Clockwise, Counter Clockwise; 


dmeaa-l-F]ight_PIan_Name-R03 

(referential att ribute ) 

fp- 1-Name. 


dmeaa-l-Turn_Center_Wpt_Name-R04 

(referential attribute) 

This attribute names the center of the circle used for the DME Arc 
acquisition. To be valid, the distance from this Tum Center to the 
current WFP must be equal to the distance from this Tum Center to the 
previ ous WFP. (That is, die two radii must be equal.) 

wpt- 1-Name. 


dmeaa - 1 - Way point_Name-R03 

(referential att ribute} 

I wpt-Name. 
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6.1.18 EC--Effector_Controller 

( external , anonymous object class, no attributes ) The Effector_Controller accepts 
requests to change certain “point mass” characteristics of the airplane (e.g., 
airspeed, bank, pitch, vertical acceleration). It translates these requests into one 
or more commands to the primary control effectors of the aircraft: aileron, 
elevator, rudder, stabilizer, engine (via throttle lever position). 

Note that in this analysis, where there may typically exist multiple coupled 
surfaces (e.g., upper and lower rudders), die surfaces are taken together as 
(logically) a single effector. 

Note: this object class is a “pseudo external object class": treated as external 
until such time as this aspect of the system can be analyzed further. For the 
interim, this object class provides a source and sink for closely related events 
and data. Further analysis may reveal that this single placeholder must become 
several object classes. Also, several of these pseudo external object classes 
might be split and joined. 


Primary Identifier: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 


Summary 


none 

ec-2-Commanded_Aileron_Position 

ec-2-Commanded_Elevator_Position 

ec-2-Commanded_Rudder_Position 

ec-2-Commanded_Stabilizer_Position 

ec-2-Commanded_Throttle_Position 


Definitions 

ec-2-Commanded_Aileron_Position 

( derived attribute ) 

| domn-Aileron_Position. 


ec-2-Commanded_Elevator_Position 

(i derived attribute ) 

I domn-Elevator_Position. 


ec-2-Commanded_Rudder_Position 

(i derived attribute ) 

I domn-Rudder_Position. 


ec-2-Commanded_Stabilizer_Position 

(derived attribute ) _ 

I domn-Stabilizer_Position. 


ec-2-Comman ded_Th rott!e_Position 

(derived attribute ) 

I domn-Engine_Throttle_Position. 
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6.1.19 ELEV— Elevator 

(external, anonymous object class, no attributes) The Elevator is one of the 
aerodynamic control effectors used to control the motion of the aircraft. All 
elevator surfaces are taken together here to be (logically) a single effector. 


Summary 

Primary Identifier: none 

Derived Attribute: elev-2-Current_Position 


Definitions 


eIev-2-CurrentJPosition 

(derived attribute) 

This i s the current sensed position of the elevator. 
I domn*Elevator_Position. 
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6.1.20 


ENG— Engine 

( external , anonymous object class) The Engine is one of the control effectors used to 
control the motion of the aircraft. All the engines are taken together as a single 
entity. 


Primary Identifier: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 


Summary 


none 

eng-2-Currcnt_Engine_Prcssure_Ratio 
eng-2-Current_Exhaust_Gas_Temperature 
eng-2-Current_N 1_RPM 
eng-2-Current_N2_RPM 
eng-2-Current_Throttle_Position 


Definitions 


eng-2-Current_Engine_Pressure_Ratio 

(i derived, attribute ) 

domn-Engine_Pressure_Ratio. 


eng-2-Current_Exhaust_Gasjremperature 

( derived attrib ute ) 

domn-Exhaust_Gas_Temperature. 


eng-2-Current_Nl_RPM 

(derived attribute ) 

domn-Engine_RPM. 


eng-2-Current N2_RPM 

(derived adribpZ 

I domn-Engine_RPM 


eng-2-Current_ThrottIe_Position 

(derived attrib ute ) 

I domn-Engine_Throttle_Position. 
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6.1.21 


FFD— Forward_Flight_Deck_Crew 

{external, anonymous object class, no attributes) The Forward_Flight_Deek_Crew 
consists of the safety pilots who fly the aircaft in the forward flight deck. 


Primary Identifier: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 


Summary 


none 

ffd-2-AFD_Designated 

ffd-2- Colu mn_Position 

ffd-2-FFD_Designated 

ffd-2-Rudder_Pedal_Position 

ffd-2-Wheel_Position 


Definitions 


ffd-2-AFD_Designated 

{derived attribute) 

“True” when the Forward Flight Deck Crew has selected Aft Flight 
Deck control of the aircraft 

I domn-Boolean. 


ffd-2-Column_Position 

{derived attribute) 

The c ontrol input which indicates the desired Pitch Angle of th e aircraft. 
I domn-Column_Position. 


ffd-2-FFD_Designated 

{derived attribute) 

“True” when the Forward Flight Deck Crew has selected Forward 
Flight Deck control of the aircraft. 

I domn-Boolean. I 


ffd-2-Rudder_Pedal_Position 

{derived attribute) 

The c ontrol input which indicates the desired Yaw Angle of the aircraft. 
| domn-Rudder_Pedal_Position. 


ffd-2-WheeIJPosition 

{derived attribute) 

The control input which indicates the desired Bank Angle of the aircraft. 
I domn-WheelJPosition. 
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6.1.22 


FFDCWS— Fwd_Flight_Deck_Control__WheeI_Steering_Mode_- 
Controller 

(anonymous object class) The Forward_Flight_Deck_Control_Wheel_Steering_- 
Mode_Controller, while engaged, maintains the attitude of the aircraft by 
issuing commands to the Effector_Controller. The FFDCWS allows the FFD_- 
Crew to change the attitude-being-maintained by responding to wheel/column 
inputs (or equivalent control inputs) while engaged. 


Primary Identifier: 
Alias: 

Behavior Model: 
Process Model: 
Attribute: 

Attribute: 

Attribute: 

Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Process: 

Process: 


Summary 

none 

ACWS Mode Controller 

present 

present 

ffdcws- l-Selected_Bank_Angle 

ffdcws-l-Selected_Pitch_Angle 

ffdcws- 1 -Selected JYaw_Angle 

ffdcws-2-Commanded_Bank_Angle 

ffdcws-2-Commanded_Pitch_Angle 

ffdcws-2-Commanded_Y aw_Angle 

ffdcws-2-ForwardJFlight_Deck_CWS_Engaged 

Set_Selected_Attitude_to_Actual 

Maintain_Attitude_of_Aircraft 


Definitions 


ffdcws-1 -Selected JBank_Angie 

(attribute) 

domn-Bank_Angle. 


ffdcws-l-Selected_Pitch_Angle 

(attribute) 

domn-Pitch_Angle. 


ffdcws-1 *SeIected__Ya w^Angle 

(attribute) _________________ 

domn-Yaw_Angle. 


ffdcws-2-Commanded_Bank_Angie 

(derived attrib ute) 

domn-Bank_Angle. 


ffdcws-2-Commanded_Pitch_Angle 

(derived attrib ute ) 

domn-Pitch_Angle. 


ffdcws-2-Commanded_Yaw_Angle 

(derived attribute ) 

domn-Yaw_Angle. 


80 




ffdcws-2-Forward_Flight_Deck_CWS_Engaged 

(i derived attribute) 

“True” while the FFDCWS is engaged (i.e., controlling the aircraft so 
as to maintain an attitude); “false” when disengaged. 

| domn-Boolean. 

Set_Selected_AttitudeJo_Actual 

(process) 

This process makes the selected attitude (pitch, bank, yaw) of the 
aircraft equal to the instantaneous actual attitude. 

Maintain_Attitude_of_Aircraft 

(process) 

This process commands the Effector_Controller to maintain the selected 
attitude (pitch, bank, yaw) of the aircraft, while at the same time 
allowing the Aft Flight Deck Crew to modify this selected attitude via 
control inputs. 
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Figure 6. 1 1 Behavior Model Diagram for FFDCWS 




F^_FHoW_D#ck_Cootrol_Wh*dLSto«flnflLMod#_,Contfoll*f 



Figure 6.12 Process Model Diagram for FFDCWS 
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6.1.23 


FP— Flight_PIan 

(regular object class) A Flight_Plan is a scheduled path through space for an 
aircraft to follow. The scheduled path may be specified in two, three or four 
dimensions. When fewer than four dimensions are specified, the remaining 
dimensions are unconstrained and are determined by the pilot or system “on the 
fly” during flight. Different parts of the path may be specified in different 
numbers of dimensions. The path may contain so-called “discontinuities,” 
which arise due to modifications which delete part of the path. (The 
discontinuity exists until and unless the end and start points are explicitly 
“joined.”) 

The AFD Crew specifies a Flight_Plan by listing an ordered sequence of 
Waypoints, possibly creating “pilot-defined” Waypoints in the process, but 
generally referencing pre-existing Waypoints. Whole strings of Waypoints may 
be specified in the creation process by referencing SIDs, STARs, Company 
Routes and/or Published Airway Routes (which themselves are ordered 
sequences of Waypoints). A list of Waypoints without additional information 
determines a two-dimensional Flight Plan. Additional constraints may be 
placed on individual Waypoints on the Flight Plan, such as specifying an 
Altitude (to form a 3-D Waypoint) and possibly a Planned Time of Arrival (to 
form a 4-D Waypoint); alternatively, SID/STAR-like constraints may be placed 
on a Waypoint (or such constraints copied from pre-existing SIDs and STARs 
may be modified). 

A “Flight Plan” as commonly thought of in the aviation community begins at a 
Runway at one Airport and ends at another Runway at another Airport. 
However, this is the ideal, complete flight plan. The intermediate stages that 
exist during creation and editing are also FP-Flight_Plans, strictly speaking 
(merely incomplete ones). 


Primary Identifier: 
Process Model: 
Attribute: 

Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Process: 


Summary 

fp-l-Name. 

present 

fp-l-Name 

fp-2-Horizontal_Guidance_Possible 
fp-2-Time_Guidance_Possible 
fp-2- Vertical jGuidanceJPossible 
Modify_Provisional_Flight_Plan 


Definitions 


fp-l-Name 

(attribute) 




Type: Enumeration; 

Values: Active, Provisional; 
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fp-2-Horizontal_Guidance_Possib!e 

(derived attribute) 

“True” when 3 or more 4-D Waypoints exist in the Provisional Flight_- 
Plan without discontinuities; “False” otherwise. 

I domn-Boolean. "™~1 


fp-2-Time_Guidance_Possible 

(derived attribute) 

‘True” when 3 or more 4-D Waypoints exist in the Provisional Flight_- 
Plan without discontinuities; “False” otherwise. 

I domn-Boolean. 


fp-2-Vertical_Guidance_Possible 

(derived attribute) 

‘True” when 3 or more 4-D Waypoints exist in the Provisional Flight- 
Plan without discontinuities; “False” otherwise. 

I domn-Boolean. I 


Modify_Provisional_Flight_PIan 

(process) 

This process allows the insertion and deletion of Waypoints in the 
provisional Flight Plan. This process allows the pilot to insert whole 
strings of Waypoints into the provisional flight plan via reference to 
route entry/exit Waypoints. Any route known by the system can be 
used for this purpose: Published Airway Routes, Company Routes, as 
well as SIDs and STARs. 

Deletion of a Waypoint in the middle of a Flight Plan shall create a 
“discontinuity” in the Flight Plan. 

This process allows two Waypoints in the provisional Flight Plan to be 
“joined,” wherein all Waypoints in between the two (if any) are deleted, 
and no discontinuity arises. (This is used to resolve a discontinuity.) 
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6.1.24 


FPAHMC-FHght_Path_AngIe_Hold_Mode_Controller 

(anonymous object class) The Flight_Path_Angle_Hold_Mode_Controller, when 
engaged, generates steering commands so as to capture and hold a pilot-selected 
flight path angle. It issues a vertical acceleration steering command to the 
Effector_Controller. 


Primary Identifier 
Behavior Model: 
Process Model: 
Attribute: 

Derived Attribute: 
Process: 

Process: 

Process: 

Process: 

Process: 

Process: 

Process: 


Summary 


none 

present 

present 

fpahmc- 1 -Selected_Flight_Path_Angle 

fpahmc-2-Commanded_Vertical_Acceleration 

Display_Actual_Flight_Path_Angle 

Display_Selected_Right_Path_Angle 

Set_Selected_Flight_Path_Angle_to_Actual 

Increment_Selected_Flight_Path_Angle 

Decrement_Selected_Flight_Path_Angle 

Display_State 

Capture_and_Hold_Selected_Flight_Path_Angle 


Definitions 


fpahmc-l-Selected_Flight_Path_Angle 

(i attribute ) 

domn-Flight_Path_Angle. 


fpahmc-2-Commanded_Vertical_Acceleration 

(derived attribute ) 

I domn- Acceleration. 


DispIay_Actual_Flight_Path_Angle 

(process) 

This process displays the Actual_Flight_Path_Angle of the aircraft. 
DispIay_Selected_Flight_Path_AngIe 

(process) 

This process displays the Selected_Flight_Path_Angle. 

Set_Selected_Flight_Path_Angie_to_Actual 

(process) 

This process makes the Selected_Flight_Path_Angle attribute equal to 
the instantaneous Actual_Flight_Path_Angle. 

Increment_Selected_FIight_Path_AngIe 

(process) 

This process increases the current Selected_Flight_Path_Angle by 0.1 
degrees. 
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Decrement_SeIected_Flight_Path_AngIe 

(process) 

This process decreases the current Selected_Flight_Path_Angle by 0.1 
degrees. 

DispIay_State 

(process) 

This process makes visible the current state of this object. (The 
implementation of this process may display a message on a CRT, or it 
may light different colored lamps.) 

Capture_and_Hold_SeIected_Flight_Path_Angle 

(process) 

This process generates a vertical acceleration steering command so as to 
smoothly change the Actual Flight Path Angle of the aircraft to match the 
Selected Flight Path Angle. 
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Figure 6. 14 Behavior Model Diagram for FPAHMC 
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6.1.25 


GTAHMC— Ground_Track_Angle_HoId_Mode_Controller 

( anonymous object class ) The Ground_Track_Angle_Hold_Mode_Controller, 
when engaged, generates steering commands so as to capture and hold a pilot- 
selected ground track angle. It issues a bank angle steering command to the 
Effector_Controller. 


Primary Identifier: 
Behavior Model: 
Process Model: 
Attribute: 

Derived Attribute: 
Process: 

Process: 

Process: 

Process: 

Process: 

Process: 

Process: 


Summary 


none 

present 

present 

gtahmc- 1 -Selected_Ground_Track_Angle 

gtahmc-2-Commanded_Bank_Angle 

Display_Actual_Ground_Track_Angle 

Di splay_Selec ted_Ground_Track_A ngle 

Set_Selected_Ground_Track_Angle_to_Actual 

Increment_Selected_Ground_Track_Angle 

Decrement_Selected_Ground_Track_Angle 

Capture_and_Hold_Selected_Ground_Track_Angle 

Display_State 


Definitions 

gtahmc-l-Selected_Ground_Track_AngIe 

( attribute ) 

domn-Ground_Track_Angle. 


gtahmc-2-Commanded_Bank_AngIe 

(derived attrib ute ) 

domn-Bank_Angle. 


Display_Actual_Ground_Track_AngIe 

(process) 

This process displays the Actual_Ground_Track_Angle of the aircraft. 

Display _Selected_Ground_Track_Angle 

(process) 

This process displays the Selected_Ground_Track_Angle of the aircraft. 

Set_Selected_Ground_Track_Angle_to_Actual 

(process) 

This process makes the Selected_Ground_Track_Angle attribute equal 
to the instantaneous Actual_Ground_Track_Angle. 

Increment_Selected_Ground_Track_Angle 

(process) 

This process increases the current Selected_Ground_Track_Angle by 
one degree. 
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Decrement_Selected_Ground_Track_AngIe 

(process) 

This process decreases the current Selected_Ground_Track_Angle by 
one degree. 

Capture_and_Hold_SeIected_Ground_Track_Angle 

(process) 

This process generates a bank angle steering command so as to 
smoothly change the Actual_Ground_Track_Angle of the aircraft to 
match the Selected_Ground_Track_Angle. 

Display_State 

(process) 

This process makes visible the current state of this object. (The 
implementation of this process may display a message on a CRT, or it 
may light different colored lamps.) 
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6.1.26 


HPG— Horizontal_Path_Guide 

(i anonymous object class, no attributes) The HPG, while engaged, generates steering 
commands that direct the aircraft to, and maintain it on, the horizontal projection 
of the Flight_Plan. The HPG assumes the aircraft is near the leg between the 
first two waypoints of the flight plan. 


Summary 


Primary Identifier: 

none 

Behavior Model: 

present 

Process Model: 

present 

Derived Attribute: 

hpg-2-Commanded_Bank_Angle 

Derived Attribute: 

hpg-2-Engaged 

Event: 

hpg-3-Disengagement_Criteria_Triggered 

Event: 

hpg-3-Engagement_Criteria_Satisfied 

Event: 

hpg-3-Mode_Reversion 

Event: 

hpg-3-Path_Convergence 

Event: 

hpg-3-Path_Divergence 

Event: 

hpg-3-Waypoint_Acquired 

Process: 

Display_State 

Process: 

Evaluate_Engagement_Criteria 

Process: 

Evaluate_Disengagement_Criteria 

Process: 

Watch_for_Path_Divergence 

Process: 

Watch_for_Path_Convergence 

Process: 

Fly_Horiz_Comp_of_Active_Flight_Plan 


Definitions 


hpg-2-Commanded_Bank_Angle 

(i derived attribute) 

This i s the commanded bank angle which shall be attained. 
domn-Bank_Angle. 


hpg-2-Engaged 

(i derived attribute) 

“True ” when the HPG is engaged; false otherwise. 
I domn-Boolean. 


hpg-3-Disengagement_Criteria_Triggered 

(broadcast event) 

This event corresponds to a determination that the HPG must disengage, 
that is, release control of the aircraft. 

hpg-3-Engagement_Criteria_Satisfied 

(broadcast event) 

This event corresponds to a determination that the HPG can successfully 
capture the horizontal component of the flight plan. 
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hpg-3-Mode_Reversion 

(broadcast event) 

This event corresponds to the self-disengagement of the HPG. The 
event is generated to let others in the system react as they will. 

hpg-3-Path_Convergence 

(broadcast event) 

This event corresponds to a determination that the aircraft is physically 
moving toward the capture envelope of the current Flight Plan leg. 

hpg-3-Path_Divergence 

(broadcast event) 

This event corresponds to a determination that the aircraft is physically 
moving away from the capture envelope of the current Flight Plan leg. 

hpg-3-Waypoint_Acquired 

(broadcast event) 

This event corresponds to a determination that the “current leg” of the 
active flight plan is complete. This means that the first waypoint in the 
active flight plan should be deleted, and the aircraft should transition to 
the next leg. 

Display_State 

(process) 

This process makes visible the current state of this object. (The 
implementation of this process may display a message on a CRT, or it 
may light different colored lamps.) 

Evaluate_Engagement_Criteria 

(process) 

This process determines whether the HPG can successfully capture the 
horizontal component of the flight plan. 

EvaIuate_Disengagement_Criteria 

(process) 

This process determines whether the HPG must disengage, that is, 
release control of the aircraft. 


Watch_for_Path_Divergence 

(process) 

This process determines whether the aircraft is progressing towards the 
first path of the active flight plan, raising a signal if not. 

WatchforPathConvergence 

(process) 

This process determines whether the aircraft is progressing towards the 
first path of the active flight plan, raising a signal if so. 
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Fly_Horiz_Comp_of_Active_Flight_Plan 

(process) 

This process steers the aircraft to, and maintains it on, the horizontal 
projection of the active flight plan. 









Figure 6.19 Process Model Diagram for HPG 


99 


[reetui red input not *n*lytej 




6.1.27 ILSGS— ILS_Ground_System 

( regular object class) A real-world ILS Ground System is the collection of ground- 
based signal-generating equipment which forms the ground component of an 
ILS (Instrument Landing System). The ILSGS object class represents the 
knowledge within the system that real ILS Ground Systems exist in the real 
world; members of the ILSGS object class represent the knowledge within the 
system of particular real-world DLS Ground Systems. In other words, this is 
NOT an external object class; the system does NOT communicate (directly) with 
physical, real-world ground-based equipment. (Rather, the system talks to 
members of the external object class ILSOBS-ELS_On_Board_System, whose 
radio communication with the real-world ground systems is not documented 
explicitly.) 

A detailed description of an ILS is not given here. 


Summary 

Primary Identifier: ilsgs- 1 - Aiiport_Name-Rl 5 

+ ilsgs- 1 -Runway_N ame-R 1 5 


Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 


ilsgs- 1 -Airport_Name-R15 
ilsgs- 1 -Broadcast_Frequency 
ilsgs- 1 -Glide_Slope_Angle 
ilsgs- 1 -Runway_Name-R 15 
ilsgs- 1-ShackJPosition 


Definitions 


ilsgs-l-Airport_Name-R15 

(; referential attribute) 

This is the name of the airport at which this ILS ground system is 
locate d. 

rw- Airport_Name-R 1 3. 


ilsgs-l-Broadcast_Frequency 

(attribute) 

This is the radio frequency used for transmission by the ELS_Ground_- 
Syste m. 

domn-Radio_Frequency. 


iIsgs-l-Glide_SIope_AngIe 

(attribute) 


This is the designated appropriate approach angle for aircraft landing on 
the na med runway. 

Type: Numeric; 

Range: from 0 to o degrees; 

Accuracy: to <> degrees; 
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ilsgs-l-RunwayJName-R15 
(referential attribute) 

This is the name of the Runway at the named airport which this ELS_- 
Grou nd_System services. 

I rw-Name I 


ilsgs-l-Shack_Position 

(attribute) 

This is the location above the surface of the Earth of the broadcast 
antenna. 

I domn-Three_D_Position. 
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6.1.28 


ILSOBS— ILS_On_Board_System 

(external, anonymous object class, no attributes ) The ILS_On_Board_System is an 
external, anonymous object class which can determine the deviation of the 
aircraft from the path defined via radio communication by a nearby ILS Ground 
System. 

Summary 

Primary Identifier: none 

Derived Attribute: ilsobs-2-Lateral_Deviation 

Derived Attribute: ilsobs-2-Signal_Strength 

Derived Attribute: ilsobs-2- Vertical_Deviation 


Definitions 


ilsobs-2-Lateral_Deviation 

(derived attribute) 

The l ateral component of the aircraft position error. 

Type: Numeric; 

Range: from <> to o feet; 

Accuracy: <>; 


ilsobs-2-Signal_Strength 

(derived attribute) 

A measure of the reliability of the signal being received from the 
groun d-based system by the on-board system. 

Type: Numeric; 

Range: <>; 

Accuracy: <>; 


i!sobs-2-VerticaI_Deviation 

(derived attribute) 

The v ertical component of the aircraft position error. 

Type: Numeric; 

Range: from <> to o feet; 

Accuracy: <>; 
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6.1.29 ISN-Intersection 

(i regular object class) An Intersection is an ATC_Named_Waypoint which is not a 
Navigational_Aid. Its five-letter name is officially given and its location is 
known. 


Summary 

Primary Identifier: isn- 1 -Name-R 1 8 

Attribute: isn- 1 -Name-R 18 

Attribute: isn- 1 -Prcferred_Nav_Aid-R 1 9 


Definitions 

isn-l-Name-R18 

(referential att ribute ) 

I atcwpt-Name. 


isn-l-Preferred_Nav_Aid-R19 

(referential att ribute ) 

I navaid-Name. 
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6.1.30 MANEL— Manual_Electric_Mode_ControlIer 

( anonymous object class, no attributes) The Manual_Electric_Mode_Controller, 
while engaged, provides rudimentary transformation of the AFD control inputs; 
the aircraft is essentially being flown manually. 


Primary Identifier: 
Behavior Model: 
Process Model: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Process: 


Summary 


none 

present 

present 

manel-2-Commanded_Bank_ Angle 
manel-2-Commanded_Pitch_Angle 
manel-2-Commanded_Yaw_Angle 
Enhance_Pilot_Control_Inputs 


Definitions 

manel-2-Commanded_Bank_Angle 

( derived attribute ) 

I domn-Bank_Angle. 


manel-2-Commanded_Pitch_AngIe 

{derived attribute ) 

domn-Pitch_Angle. 


manel-2-Commanded_Yaw_Ang!e 

{derived attribute ) 

I domn-Yaw_Angle. 


Enhance_PiIot_Control_Inputs 

(process) 

This process provides rudimentary transformation of the AFD control 
inputs. The aircraft is essentially being flown manually. 
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Figure 6.20 Behavior Model Diagram for MANEL 
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6.1.31 MLSGS— MLS_Ground_System 

( regular object class) A real-world MLS Ground System is the collection of 
ground-based signal-generating equipment which forms the ground component 
of an MLS (Microwave Landing System). The MLSGS object class represents 
the knowledge within the system that real MLS Ground Systems exist in the 
real world. See also ILSGS-ILS_Ground_System. 


Summary 

Primary Identifier: mlsgs-l-Aiiport_Name-R21 

+ mlsgs- 1 -Runway_N ame-R2 1 


Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 


mlsgs-l-Airport_Name-R21 

mlsgs- l-Azimuth_Broadcast_Location 

mlsgs- 1 -DME_Location 

mlsgs- 1-Flare J3roadcast_Location 

mlsgs-l-Glide_Path_Broadcast_Location 

mlsgs- 1 -Runway_Name-R2 1 


Definitions 


mlsgs- l-Airport_Name*R21 

( referential attribute) 

This i s the name of the airport at which this MLSGS is locatec .. 
rw- Airport_N ame-R 1 3. 


mlsgs* l-Azimuth_Broadcast_Location 

( compound attribute) 

This is the location of the antenna which broadcasts azimuth 
information, specified relative to the rw-Threshold of the named 
runw ay. 

domn-X_Offset_From_Runway_Threshold 
+ domn-Y_Offset_From_Runway_Threshold 
+ domn-Z_Offset_From_Runway_Threshold. 


mlsgs-l-DMEJLocation 

(i compound attribute) 

This is the location of the antenna which broadcasts distance 
infor mation, specified relative to the Azimuth_Broadcast_Loca tion. 

domn-X_Offset_From_Azimuth_Broadcast_- 

Location 

+ domn-Y_Offset_From_Azimuth_Broadcast_- 

Location 

+ domn-Z_Offset_From_Azimuth_Broadcast_- 

Location. 
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mlsgs-l-Flare_Broadcast_Location 

(compound attribute) 

This is the location of the antenna which broadcasts flare information, 
speci fied relative to the Azimuth J3roadcast_Location. 

domn-X_Offset_From_Azimuth_Broadcast_- 

Location 

+ domn-Y_Offset_From_Azimuth_Broadcast_- 

Location 

+ domn-Z_Offset_From_Azimuth_Broadcast_- 

Location. 


mlsgs-l-Glide_Path_Broadcast_Location 

(compound attribute) 

This is the location of the antenna which broadcasts glide slope 
infor mation, specified relative to the Azimuth_Broadcast JLoca tion. 

domn-X_Offset_From_Azimuth_Broadcast_- 

Location 

+ domn-Y_Offset_From_Azimuth_Broadcast_- 

Locadon 

+ domn-Z_Offset_From_Azimuth_Broadcast_- 

Location. 


mlsgs-l-Runway_Name-R21 

(referential attribute) 

This i s the name of the runway which this MLSGS services. 

______ 
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6.1.32 


MLSOBS~MLS_On_Board_System 

( external , anonymous object class, no attributes) The MLS_Aircraft_System is an 
external, anonymous object class which can determine the deviation of the 
aircraft from the path defined via radio communication by a nearby MLS 
Ground System. 

Summary 


Primary Identifier. 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 


none 

mlsobs-2-Lateral_Deviation 

mlsobs-2-Signal_Strength 

mlsobs-2-Vertical_Deviation 


Definitions 


mIsobs-2-Lateral_Deviation 

(i derived attribute) 

The l ateral component of the aircraft position error. 

Type: Numeric; 

Range: from <> to <> feet; 

Accuracy: o; 


mlsobs-2-SignaI_Strength 

(i derived attribute) 

A measure of the reliability of the signal being received from the 
groun d-based system by the on-board system. 

Type: Numeric; 

Range: <>; 

Accuracy: <>; 


mIsobs-2-Vertical_Deviation 

(i derived attribute) 

The v ertical component of the aircraft position error. 

Type: Numeric; 

Range: from <> to o feet; 

Accuracy: o; 
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6.1.33 


NAVAID— NavigationalAid 

(i regular object class) A real-world Navigational Aid (aka Nav Aid) is a radio 
broadcast device located on the surface of the earth designed to enable an 
aircraft to determine its latitude and longitude (so long as the aircraft is within 
the service range of the Nav_Aid). The NAVAID object class represents the 
knowledge within the system that real Navigational Aids exist in the real world; 
members of the NAVAID object class represent knowledge within the system of 
particular real-world nav aids. In other words, this is NOT an external object 
class: the system does NOT communicate (directly) with physical, real-world, 
on-the-ground nav aids. (Rather, the system communicates only directly with 
aircraft on-board receivers and other sensors.) 

Every NAVAID is an example of an ATCWPT; that is, the NAVAID object 
class is subtype of the ATCWPT object class. 

The navaid-Name is the official name designated by the FAA. Nav_Aids are 
called out on air navigation charts. “Navigational Aid” is a generally recognized 
term of the aviation community. 


Primary Identifier: 
Alias: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 


Summary 

navaid-l-Name 
Nav_Aid, nav aid, navaid; 
navaid- 1 -Elevation 
navaid- 1 -Frequency 
navaid-l-Name 
navaid- 1 -Service_Range 
navaid-l-Type 


Definitions 


navaid-l-Elevation 

{attribute) 

This i s the height of the nav aid's broadcast antenna. 
I domn-Altitude_Above_Mean_Sea_Level. 


navaid-l-Frequency 

{attribute) 


The broadcast frequency of this nav aid. For VOR/DMEs, this is the 
VOR frequency; DME frequency is derivable from this. 

Type: Numeric; 

Range: from 108.0 to 1 17.9 MHz; 

Accuracy: to 0.1 MHz; 


navaid-l-Name 

{attribute) 

This i s the official identifier of the nav aid, as assigned by the F AA. 
Type: String; 

Range: exactly 3 upper case letters; 
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navaid-l-Service_Range 

(attribute) 


This indicates the general shape of the airspace above the nav aid for 
which the nav aid is certified to provide reliable broadcast signals; 
additional restrictions on this volume, due to mountains and so on, are 
not re corded within the system. 

Type: Enumeration; 

Values: Low_Altitude; High_Altitude; 


navaid-l-Type 

(attribute) 

This indicates the class of the nav aid. 


Type: 

Enumeration; 

Values: 

VOR, VOR-DME, TACAN, NDB, 


Localizer_Beacon; 
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6.1.34 PAR— Published_Airway_Route 

( regular object class ) A Published_Airway_Route is an officially recognized 
sequence of ATCWPTs which form a two-dimensional, bi-directional path 
across the surface of the earth. The par- 1 -Number is the official designation of 
the FAA. Given just any sequence of ATCWPTs, these may or may not form 
an official PAR Published_Airway_Routes are called out on air navigation 
charts. 

At the time of this writing, Published_Airway_Routes are divided into two 
categories (types): “low altitude routes” and “high altitude routes”, also known 
as “Victor Airways” and “Jet Airways” (respectively). 


Primary Identifier. 


Attribute: 

Attribute: 


Summary 

par- 1-Type 
+ par- 1 -Number. 

par- 1 -Number 
par- 1-Type 


Definitions 


par-l-Number 

(attribute) 

This is the unique id of the route, as assigned by the FAA. It is only 
uniqu e within it's class (type). 

Type: Integer; 

Range: from 1; 


par-l-Type 

(attribute) 

This i s the class of the route. 

Type: Enumeration; 

Values: Victor, Jet; 
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6.1.35 PCWPT— PiIot_or_Company_Defined_Waypoint 

( regular object class) A PCWPT is an unofficial Waypoint, defined by a company 
as a standard reference for all pilots within the company, or defined by a pilot 
for use during a particular flight. 


Primary Identifier: 

Attribute: 

Attribute: 

Attribute: 


Summary 

pcwpt- 1 -Name-R 1 7 

pswpt-l-Name-R17 

pcwpt- 1 -Preferred_Nav_Aid-R05 

pcwpt- l-Primary_Use_Description 


Definitions 


pcwpt-l-Name-R17 

(i referential att ribute ) 

| wpt-l-Name. 


pcwpt-l-Preferred_Nav_Aid-R05 

(referential att ribute ) 

I navaid- 1-Name. " ™ 


pcwpt- 1-Primary JUse_Description 

(attribute) 

A short English description of the primary purpose for which this 
wayp oint was created (e.g., “DME arc center”). 

Type: String; 
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6 . 1,36 


RA~Restricted_Area 

( regular object class) A Restricted_Area is an air traffic control area requiring 
explicit entry authorization by the controlling ATC facility. In this analysis, a 
Restricted_Area always takes the shape of a polygon, which is defined by its 
vertices (see Restricted_Area_Vertex). “Restricted Area” is an official term; 
however, we use the term colloquially, so that ADIZs, CADIZs, etc., are 
included as members of this class. 


Primary Identifier: 
Attribute: 

Attribute: 


Summary 

ra-l-Name 

ra-l-Name 

ra-l-Type 


Definitions 


ra-l-Name 

(attribute) 


The official name of the restricted area. 


ra-l-Type 

(attribute) 


Type: 

String; 

- 

Type: 

Enumeration; 

Values: 

Air Defense Intercept Zone, 


Coastal Air Defense Intercept Zone, 


Restricted Area, o; 
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6.1.37 R A V— Rest ricted_Area__Vertex 

( regular object class) A Restricted_Area_Vertex is a vertex of a polygon which 
defines a Restricted_Area. It does not necessarily coincide with any other 
geographic reference point. “Restricted Area Vertex” is not a generally used 
term, but is more or less self-explanatory. 

Summary 

rav-l-Restricted_Area J^ame-R 1 6A 
+ rav- 1 - Vertex_Number 

rav-l-Latitude 
rav- 1-Longitude 

rav-l-Restricted_Area_Name-R16A 
rav- 1 -Vertex_N umber 


Primary Identifier 


Attribute: 

Attribute: 

Attribute: 

Attribute: 


Definitions 


rav-l*Latitude 

(attribute) 

The l atitude of the vertex, 
I domn-Latitude. 


rav-1 -Longitude 

(attribute) 

The l ongitude of the vertex. 
domn-Longitude. 


rav-l-Restricted_Area_Name-R16A 

(referential attribute) 

The i d of the Restricted Area of which this is a vertex. 
I ra-Name. 


rav-l-Vertex_Number 

(attribute) 

The position of this vertex in the sequential vertex list. The line 
connecting this vertex with its successor defines one edge of the 
polygonal Restricted Area. Numbering the vertices is necessary to 
unam biguously define the polygon. 

Type: Integer 

Range: from 1; 
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6.1.38 


RUD-Rudder 

(i external , anonymous object class, no attributes ) The Rudder is one of the 
aerodynamic control effectors used to control the motion of the aircraft. 

Summary 

Primary Identifier: none 

Derived Attribute: rud-2-Current_Position 


Definitions 


rud-2-CurrentJPosition 

(derived attribute) 

The c urrent sensed position of the rudder. 
I domn-Rudder_Position. 
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6.1.39 RW-Runway 

( regular object class) A Runway is a strip of pavement on which an aircraft lands in a 
particular direction. A given strip of pavement (airstrip) plays the role, at different 
times, of two distinct Runways (e.g., 10L and 28R). Thus the term “Runway” refers to 
one of the roles played by an airstrip rather than to the physical airstrip itself. 


Summary 

Primary Identifier: rw-l-Name 

+ rw- 1 - Airport_Name-R 1 3 

rw- 1 - Airport_N ame-R 1 3 
rw- 1 -Magnetic_Heading 
rw- l-Missed_Appr_Point 
rw-l-Name 
rw-1 -Threshold 
rw- 1 -U sable_Len gth 


Definitions 

rw-l-Airport_Name-R13 

(referential attribute ) 

The n ame of the Airport at which this Runway is located. 
ap-Name. 


Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 


rw-l-Magnetic_Heading 

(attribute) 

The magnetic heading of the Runway. 

Type: Numeric; 

Range: from 0 to 360 degrees; 

Accuracy: to 1 degree; 


rw-l-Missed_Appr_Point 

(attribute) 

The location on the surface of the earth over which the pilot must make 
his go - around decision. 

I domn-Two_D_Position. 
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rw-l-Name 

(attribute) 

This is the official name of the Runway, which is determined by (1) its 
Magnetic_Heading, and (2) its position at the Airport relative to a 
runway parallel to it (if one exists). In the format “nh”, 'n' is a string of 
1 to 2 digits equal to the magnetic heading rounded to the nearest 10 
degrees; 'h' is either “L” or “R” (for left-hand runway and right-hand 
runway, respectively). If there is no parallel runway, then the 'h' is 
dropped. 


Type: 

String; 

Range: 

from 1 to 3 characters; 

Format: 

nh; 


rw-l-Threshold 

(attribute) 

The l ocation of the beginning of the usable part of the Runway . 
I domn-Two_D_Position. 


rw-l-Usable_Length 

(attribute) 

The u sable length of the Runway, starting from the Threshold. 

Type: Numeric; 

Range: from 0 to o feet; 

Accuracy: to 1 foot; 
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6.1.40 


SDF~Sensor_Data_Filterer 

(external, anonymous object class, no attributes) The Sensor_Data_Filterer reads the 
raw data provided by the external object class SENS-Sensor_Suite, translating, 
filtering and validating this data. Some of the data provided by the SENS- 
Sensor_Suite may be simply “passed through”. The mapping from sensed data 
to SDF data is non-trivial. 

Note: this object class is a “pseudo external object class": treated as external 
until such time as this aspect of the system can be analyzed further. For the 
interim, this object class provides a source and sink for closely related events 
and data. Further analysis may reveal that this single placeholder must become 
several object classes. Also, several of these pseudo external object classes 
might be split and joined. The array of inputs from the sensor suite is not 
known at the time of this writing. 


Summary 


Primary Identifier: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Derived Attribute: 


none 

sdf-2-Altitude_Above_Ground_Level 

sdf-2-Altitude_Above_Mean_Sea_Level 

sdf-2-Angle_of_Attack 

sdf-2-Bank_Angle 

sdf-2-Bank_Angle_Rate_of_Change 

sdf-2-Flight_Path_Angle 

sdf-2-Ground_Track_Angle 

sdf-2-Ladtude 

sdf-2-Longitude 

sdf-2-Piteh_Angle 

sdf-2-Pitch_Angle_Rate_of_Change 

sdf-2-Sideslip_Angle 

sdf-2-True_Airspeed 

sdf-2-Wind_Velocity 

sdf-2-X_Acceleration 

sdf-2-Y_Acceleration 

sdf-2-Yaw_Angle 

sdf-2-Yaw_Angle_Rate_of_Change 

sdf-2-Z_Acceleration 


Definitions 


sdf-2-AItitude_Above_Ground_Level 

(derived attribute) 

This i s the current altitude of the aircraft. 

I domn*Altitude_Above_Ground_Level. 


sdf-2-Altitude_Above_Mean_Sea_Level 

(derived attribute) 

This i s the current altitude of the aircraft. 

I domn-Altitude_Above_Mean_Sea_Level. 
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sdf-2-Angle_of_Attack 

(i derived attribute) 

This i s the angle of attack of the aircraft 

Type: Numeric; 

Range: from o to o degrees; 

Accuracy: to o degrees; 


sdf-2-Bank_Angle 

(< derived attribute ) 

I domn-Bank_Angle. 


sdf-2-Bank_Angle_Rate_of_Change 

(derived attrib ute) 

Type: Numeric; 

Range: from <> to o degrees per second; 

Accuracy: o; 


sdf-2-Flight_Path_Angle 

(derived attrib ute ) 

domn-Flight_Path_Angle. 


sdf-2-G round JTrack^Angle 

(derived attrib ute ) 

domn-Ground_Track_Angle. 


sdf-2-Latitude 

(derived attribute) 

This i s the current latitude of the aircraft. 
I domn-Latitude. 


sdf-2-Longitude 

(derived attribute) 

This i s the current longitude of the aircraft 
I domn-Longitude. 


sdf-2-Pitch_Ang!e 

(derived attribute ) 

I domn-Pitch_Angle. 


sdf-2-Pitch_AngIe_Rate_of_Change 

(derived attrib ute ) 

Type: Numeric; 

Range: from o to o degrees per second; 

Accuracy: o; 
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sdf-2-SideslipAngIe 

(i derived attribute) 

This i s the sideslip angle of the aircraft. 

Type: Numeric; 

Range: from o to o degrees; 

Accuracy: to <> degrees; 


sdf-2-True_Airspeed 

{derived attribute) 

This i s the true airspeed of the aircraft 
domn-Airspeed. 


sdf-2-Wind_Velocity 

{derived attribute! ____ 

Type: Numeric; 

Range: from <> to <> knots; 

Accuracy: o; 


sdf-2-X_Acceleration 

{derived attribute) 

This is the instantaneous longitudinal acceleration of the aircraft, where 
forwa rd acceleration is positive. ___ 

I domn-Acceleration. 


sdf-2-Y_Acceleration 

{derived attribute) 

This is the instantaneous lateral acceleration of the aircraft, where 
accele ration towards the right wing is positive. 

I domn-Acceleration. 


sdf-2-Yaw_Angle 

{derived attribute) 

I domn-Yaw_Angle. 


sdf-2-Yaw_Angle_Rate_of_Change 

{derived attribute ) 


Type: Numeric; 

Range: from <> to <> degrees per second; 

Accuracy: <>; 


sdf-2-Z_Acceleration 

{derived attribute) 

This is the instantaneous “vertical” acceleration of the aircraft, where the 
vertic al axis completes the right-hand coordinate system of the aircraft. 

1 domn-Acceleration. 
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6.1.41 SENS— Sensor_Suite 

(external, anonymous object class, no attributes) The Sensor_Suite is a placeholder, an 
external object class used to provide a simplified source of sensed data until 
such time as this aspect of the system can be analyzed further. The array of data 
provided by the SensorJSuite (to the SDF) is not known; hence there are no 
definitions given for this object class of any derived attributes. Rather, this 
object class serves merely to document the existence of some set of raw data, 
which can be used to derive the set of data provided by the SDF. 

Note that external object classes which have already been modeled provide then- 
own sensed data. The SENS object class exists as a “catch-all” for sensed data 
which does not have a clear source at the time of this writing. 


Summary 

Primary Identifier: none 
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6.1.42 


SS— SID_or_STAR 

(i regular object class ) A member of this object class is either a SID or a STAR; 
these two FAA procedures were modeled as a single object class because their 
data, behavior and process models are identical. This is due to the fact that the 
system shall give maximum flexibility to the pilot as he or she constructs a 
Flight_Plan. (That is, the system shall not constrain SIDs to be at the 
beginning, etc.) Maximum flexibility manifests itself as very generic behavior 
and processing for SIDs and STARs. 

A Standard_Instrument_Departure_Procedure is officially referred to as a SID. 
A SID is a published IFR ATC departure procedure established by the FAA. 
SIDs exist to reduce communication in the terminal area of an airport by 
providing a predefined transition route from a particular Runway to an 
appropriate en route structure. The ss-l-Name shall be the official, published 
SID name. “Standard Instrument Departure (SID)” is an official term. 

A Standard JTerminaLARrivalJProcedure is officially referred to as a STAR. A 
STAR is a published IFR ATC arrival procedure established by the FAA. 
STARs exist to reduce communication in the terminal area of an airport by 
providing a predefined transition route from an en route structure to a particular 
Runway. The ss-l-Name shall be the official, published STAR name. 
“Standard Terminal ARrival (STAR)” is an official term. 

Note that combining SIDs and STARs into a single SS object class did 
introduce a couple “wrinkles”: the introduction of the “Type” attribute, and the 
transitive dependence of “IAS Required” on the key. However, the savings in 
terms of reduced complexity provided the impetus. 


Summary 

Primary Identifier: ss-1 -Name 

+ ss-l-Type 


Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 


ss- 1 -Aiiport_Name-R 12B-R 14B-R20B 
ss-1 -IAS_Required-R 1 4B 
ss-l-Name 

ss- 1 -Runway_Name-R 1 2B -R 14B-R20B 
ss-l-Type 


Definitions 

ss-l-Airport_Name-R12B-R14B-R20B 

(referential attribute) 

The i d of the Airport at which this SS is defined. 
rw- 1 -Airport_Name-Rl 3. 


ss-l-IAS_Required-R14B 

( subtype indication) 


The type of Instrument Approach System (IAS) defined for this 
proce dure. Must be “None” for STARs; may be “None” for S IDs. 


Type: Enumeration; 

Values: ILS, MLS, None; 
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ss-i-Name 

(attribute) 

The o fficial id of the SID/STAR, unique across all Airports. 

Type: String; 

Range: o; 

Format: o; 


ss-l”Runway_Name-R12B-R14B-R20B 

(referential attribute) 

The id of the Runway for which this procedure is defined; for SIDs, this 
is the Runway of origin; for STARs, this is the destination Ru nway. 

j rw-l-Name, 


ss-l-Type 

(attribute) 

The c lass of procedure. 

Type: Enumeration; 

Values: SID, STAR; 




6.1.43 STAB— Stabilizer 

0 external , anonymous object class, no attributes ) The Stabilizer is one of the 
aerodynamic control effectors used to control the motion of the aircraft 

Summary 

Primary Identifier: none 

Derived Attribute: stab-2-Cunent_Position 


Definitions 


stab-2-Current_Position 

(i derived attribute) 

The c urrent sensed position of the Stabilizer. 
domn-Stabilizer_Position. 
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6.1.44 


TOBJ~Terrain_Object 

(regular object class) A Terrain Object is any physical obstruction to flight of 
which a pilot should be aware. A Terrain Object known to the system can 
appear on a map display, for instance, or be used to validate a flight plan. 


Primary Identifier: 


Attribute: 

Attribute: 

Attribute: 

Attribute: 


Summary 

tobj-l-Latitude 
+ tobj-l-Longitude 

tobj- 1-Elevation 
tobj-l-Latitude 
tobj-l-Longitude 
tobj- 1-Type 


Definitions 


tobj-l-Elevation 

(attribute) 

I domn-Altitude_Above_Ground_Level. 


tobj-l-Latitude 

(attribute) 

I domn Latitude. 


tobj-l-Longitude 

(attribute) 

domn-Longitude. 


tobj-l-Type 

(attribute) 

Type: Enumeration; 

Values: Mountain, Obstruction; 
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6.1.45 


TPG~Time_Path_Guide 

(i anonymous object class, no attributes) The TPG, while engaged, generates steering 
commands that direct the aircraft to, and maintain it on, the time projection of 
the Flight JPlan. The TPG assumes die aircraft is near the leg between the first 
two waypoints of the flight plan. 


Primary Identifier: 
Behavior Model: 
Process Model: 
Derived Attribute: 
Process: 

Process: 


Summary 

none 

present 

present 

tpg-2-Commanded_Airspeed 

Display_State 

Fly_Time_QMnp_of_Active_Flight_Plan 


Definitions 


tpg-2-Commanded_Airspeed 

{derived attribute) 

This i s the commanded airspeed which the aircraft shall attain. 
domn- Airspeed. 


DisplayJState 

(process) 

This process makes visible the current state of this object. (The 
implementation of this process may display a message on a CRT, or it 
may light different colored lamps.) 


Fly_Time_Comp_of_Active_Flight_Plan 

(process) 

This process steers the aircraft to, and maintains it on, the time 
projection of the active flight plan. 
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6.22 Behavior Model Diagram for TPG 
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[required inpuy/'not analyzed) 



6.1.46 VCWS~Velocity_Vector_Hold_CWS_Mode_Controller 

( anonymous object class) The VCWS Mode Controller, while engaged, maintains 
the velocity vector (i.e., ground track angle and flight path angle) of the aircraft 
by issuing commands to the Effector_Controller. The VCWS allows the 
AFD_Crew to change the velocity-vector-being-maintained by responding to 
wheel/column inputs (or equivalent control inputs) while engaged. 


Primary Identifier: 
Alias: 

Behavior Model: 
Process Model: 
Attribute: 
Attribute: 

Derived Attribute: 
Derived Attribute: 
Derived Attribute: 
Process: 

Process: 


Summary 


none 

VCWS Mode Controller 

present 

present 

vcws-l-Selected_Flight_Path_Angle 

vcws-l-Selected_Ground_Track_Angle 

vcws-2-Commanded_Bank_Angle 

vcws-2-Q)mmanded_Vertical_Acceleration 

vcws-2-Velocity_Vector_HoldJEngaged 

Set_Selected__Velocity_Vector_to_Actual 

Maintain_Velocity_Vector_of_Aircraft 


Definitions 

vcws-l-Selected_Flight_Path_AngIe 

(attribute) 

I domn-Flight_Path_Angle. 


vcws-l-Selected_Ground_Track_Angle 

(t attribute ) _ 

I domn-Ground_Track_Angle. 


vcws-2-Commanded_Bank_Angle 

{derived attrib ute) 

I domn-Bank_Angle. 


vcws-2-CommandedVerticaIAcceleration 

(derived attribute ) 

j domn-Acceleration. 


vcws-2-Velocity_Vector_Hold_Engaged 

(derived attribute) 

“True ” when the VCWS is engaged; “False” otherwise. 
I domn-Boolean. 
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Set_SeIected_Velocity_Vector_to_ActuaI 

(process) 

This process makes the selected velocity vector (flight path angle and 
ground track angle) of the aircraft equal to the instantaneous actual 
velocity vector. 

Maintain_Velocity_Vector_of_Aircraft 

(process) 

This process commands the Effector_Controller to maintain the selected 
velocity vector (flight path angle and ground track angle) of the aircraft, 
while at the same time allowing the Aft Flight Deck Crew to modify this 
selected velocity vector via control inputs. 
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V«kw^V«cter - HoW_ComfoLW»^_8t^lnfl_Mod^Controltef 
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6.1.47 


VPG— VerticaI_Path_Guide 

( anonymous object class, no attributes) The VPG, while engaged, generates steering 
commands that direct the aircraft to, and maintain it on, the vertical projection of 
the Flight_Plan. The VPG assumes the aircraft is near the leg between the first 
two waypoints of the flight plan. 


Primary Identifier: 

Summary 

none 

Behavior Model: 

present 

Process Model: 

present 

Derived Attribute: 

vpg-2- Armed 

Derived Attribute: 

vpg-2-Commanded_Vertical_Acceleration 

Derived Attribute: 

vpg-2-Engaged 

Event: 

vpg-3-Engagement_Criteria_Satisfied 

Event: 

vpg-3-Mode_Reversion 

Event: 

vpg-3-Path_Convergence 

Event: 

vpg-3-Path_Divergence 

Process: 

Display_State 

Process: 

Evaluate_Engagement_Criteria 

Process: 

Evaluate_Disengagement_Criteria 

Process: 

W atch_for_Path_Divergence 

Process: 

Watch_for_Path_Convergence 

Process: 

Fly_Vertical_Comp_of_Active_Flight_Plan 


Definitions 

vpg-2-Armed 

(derived attribute) 

“True ” when the VPG is either armed or engaged; “False” othe rwise. 
I domn-Boolean. 


vpg-2-Commanded_Vertical_Acceleration 

(derived attribute) 

This i s the commanded vertical acceleration which shall be atta ined. 
I domn-Vertical_Acceleration. 


vpg-2-Engaged 

(derived attribute) 

“True ” when the VPG is engaged; “False” otherwise. 
I domn-Boolean. 


vpg-3-Engagement_Criteria_Satisfied 

(broadcast event) 

This event corresponds to a determination that the VPG can successfully 
capture the vertical component of the flight plan. 
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vpg-3-Mode_Reversion 

(broadcast event) 

This event corresponds to the self-disengagement of the VPG. The 
event is generated to let others in the system react as they will. 


vpg-3-Path_Convergence 

(broadcast event) 

This event corresponds to a determination that the aircraft is physically 
moving toward the vertical projection of the flight plan. 


vpg-3-Path_Divergence 

(broadcast event) 

This event corresponds to a determination that the aircraft is physically 
moving away from the vertical projection of the flight plan. 

Display_State 

(process) 

This process makes visible the current state of this object. (The 
implementation of this process may display a message on a CRT, or it 
may light different colored lamps.) 


£valuate_Engagement_Criteria 

(process) 

This process determines whether the VPG can successfully capture the 
vertical component of the flight plan. 

Evaluate_Disengagement_Criteria 

(process) 

This process determines whether the VPG must disengage, that is, 
release control of the aircraft. 


Watch_for_Path_Divergence 

(process) 

This process determines whether the aircraft is progressing towards the 
first path of the active flight plan, raising a signal if not. 


WatchforPathConvergence 

(process) 

This process determines whether the aircraft is progressing towards the 
first path of the active flight plan, raising a signal if so. 

FIy_Vertical_Comp_of_Active_FIight_Plan 

(process) 

This process steers the aircraft to, and maintains it on, the vertical 
projection of the active flight plan. 
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Vertical Ptth OuW* 



Figure 6.27 Process Model Diagram for VPG 
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6.1.48 WCR~Waypoint_ona_Company_Route 

( regular object class ) A Waypoint_ona_Company_Route arises out of the 
association of a particular Waypoint (WPT) with a particular Company Route 
(CR). It captures the information relevant to such an association. (The same 
Waypoint on a different Company Route may be assigned different data 
values.) 

“Waypoint on a Company Route” is a somewhat artificial term created for the 
sake of clarity in this analysis; in general usage, the term “Waypoint” may refer 
to Waypoints, Waypoints on Company Routes, Waypoints on Flight Plans, or 
even Waypoints on SIDs or STARs (where the meaning is clear from the 
context). 

Summary 

Primary Identifier: wcr-l-Route_Name-R09B 

Attribute: wcr--l-Route_Name-R09B 

Attribute: wcr-l-Waypoint_Name-R09A 


Definitions 


wcr-l-Route_Name-RQ9B 

( referenda l attribute) 

The id of the Company Route which the named Waypoint is on by 
mean s of this WCR. 

I cr-l-Name. I 


wcr-l-Waypoint_Name-R09A 

(referential attribute) 

The id of the Waypoint which is on the named Company Route by 
mean s of this WCR. 

wpt-l-Name. 
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6.1.49 


WFP~Waypoint_onaJFIight_Plan 

(regular object class) A Waypoint_ona_Flight_Plan arises out of the association of 
a particular Waypoint with a particular Flight_Plan. It captures the information 
relevant to such an association. (The same Waypoint on a different FlightJPlan 
may be assigned different data values.) 

“Waypoint on a Flight Plan” is a somewhat artificial term created for the sake of 
clarity in this analysis; in general usage, the term “Waypoint” may refer to both 
Waypoints and Waypoints on Flight Plans (where the meaning is clear from the 
context). For that matter, the term Waypoint may refer to a Waypoint on a SID 
or STAR (see WSS). 

Summary 

wfp- 1 -Fli ght_Plan_N ame-RQ 1 A 
+ wfp- 1 -Waypoint_Name-R01 B 

Waypoint_Enrollment, Enrollment; 
wfp- 1 -Flight_Plan_Name-R01 A 
wfp- 1 -Method_of_Acquisition-R03 
wfp- 1 -Ordinal_Position_on_Plan 
wfp-l-Type-R02 
wf£- 1 -W aypoin t_N ame-ROl B 


Definitions 

fp-l-Flight_Plan_Name-R01 A 

(referential attribute) 

The id of the Flight_Plan which the named Waypoint is on by means of 
this WFP. 

fp-l-Name. 


Primary Identifier: 


Alias: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 


wfp-l-Method_of_Acquisition-R03 

(subtype indication) 

The manner in which the aircraft will move from the previous WFP to 
this WFP. 


Type: 

Subtype Indication; 

Objects: 

DA, DMEAA; 


wfp-l-Ordinal_Position_on_Plan 

(attribute) 


The sequential position (first, second, third, 
name d Flight_Plan. ■ 


.) of this WFP on the 


Type: 

Range: 


Integer, 
from 1; 
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wfp-l-Type-R02 

(subtype indication) 

The type of WFP this is; this points the way to further information 
conce rning this WFP (if any). 

Type: Subtype Indication; 

Objects: WFP2D, WFP3D, WFP4D, CWFP; 


wfp-l-Waypoint_Name-R01B 

(referential attribute) 

The id of the Waypoint which is on the named Flight_Plan by means of 
this WFP. 

j wpt-l-Name. 




6.1.50 


WFP2D— Two-D_Waypoint_ona_Flight_Plan 

(anonymous object class, no attributes) A WFP2D is a two-dimensional WFP, i.e., a 
waypoint on a flight plan which has not been assigned additional constraints, 
such as an altitude for the aircraft to be at, planned time of arrival, etc. As a 
vacuous object class, it's existence is justified only to complete the subtypes of 
WFP: it ensures that every WFP has a well-defined wfp- l-Type. 

Summary 

Primary Identifier: none 
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6.1.51 


WFP3D--Three-D_Waypoint__ona_FIight_Plan 

(regular object class) A WFP3D is a three-dimensional WFP, ie., a waypoint on a 
flight plan which has been augmented with altitude information. 

Summary 

Primary Identifier: wfp3d- l-Flight_Plan_Name-R02 

+ wfp3d-l-Waypoint_Name-R02 


Attribute: 

Attribute: 

Attribute: 


wfp3d- 1 - Altitude_to_be_at 

wfp3d-l-Flight_Plan_Name-R02 

wfp3d-l-Waypoint_Name-R02 


Definitions 


wfp3d-l-Altitude_to_be_at 

(attribute) 

The desired altitude to be at by the time the airplane arrives at the 
Wayp oint. 

I domn-Altitude_Above_Mean_Sea_Level. 


wfp3d-l-Flight_Pian_Name-R02 

(referential att ribute) 

I wfp- 1 -Flight_Plan_Name-RO 1 A. 


wfp3d-l-Waypoint_Name-R02 

(referential att ribute ) 

wfp- 1-W aypoint_Name-RO IB. 
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6.1.52 


WFP4D-- Four-DJWaypoint_ona_FIight_Plan 

( regular object class) A WFP4D is a four-dimensional WFP, i.e., a waypoint on a 
flight plan which has been augmented with both altitude and time-of-arrival 
information. 


Primary Identifier 


Attribute: 

Attribute: 

Attribute: 

Attribute: 


Summary 

wfp4d- 1 -Flight, Plan_Name-R02 
+ wfp4d-l-Waypoint_Name-R02 

wfp4d-l-Altitude_to_be_at 
wfp4d- 1 -Flight_Plan_Name-R02 
wip4d- 1 -Planned JTime_of_Amval 
wf^>4d- 1 - Waypoint_Name-R02 


Definitions 


wfp4d-l-Altitude_to_be_at 

(attribute) 

wfp3d-Altitude_to_be_at. 


wfp4d-l-Flight_Plan_Name-R02 

(referential att ribute ) 

I wfp-l-Flight_Plan_Name-R01A. 


wfp4d-l-PIanned_Time_of_ArrivaI 

(attribute) 

The ti me of day at which the airplane should arrive at the wayp oint, 
dom n-T ime_of_Day . 


wfp4d-l-Waypoint_Name-R02 

(referential att ribute } 

wfp- 1 -Waypoint_Name-R01B. 
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6.1.53 


WPT-Waypoint 

( regular object class) A Waypoint is a predetermined position on the surface of the 
Earth used for route/instrument approach definition, or progress reporting 
purposes, that is defined relative to a VOR-DME station or in terms of 
latitude/longitude coordinates. The Waypoint's name is generally user-defined; 
however, when a Waypoint coincides with an ATC_Named_Waypoint, the 
Waypoint shall be named identically. “Waypoint” is a generally recognized 
term of the aviation community. Note, however, that in general usage the term 
“waypoint” may refer to both Waypoints and Waypoints on Flight Plans (where 
the meaning is clear from the context). 


Primary Identifier: 
Process Model: 
Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 

Process: 


Summary 

wpt-1 -Name 

present 

wpt-1 -Latitude 

wpt- 1 -Location_Description 

wpt-1 -Longitude 

wpt- 1 -Magnetic.. V ariation 

wpt-l-Name 

wpt-l-Type-R17 

Create_Waypoint 


Definitions 


wpt-l-Latitude 

(i attribute ) 

I domn-Latitude. 


wpt-l-LocationJDescription 

(attribute) 

A short English description of the location of the waypoint, typically the 
name of a nearby city. 

Type: String; 

wpt-l-Longitude 

(attribute) ________ 

| domn-Longitude. 


wpt-l-Magnetic_Variation 

(attribute) 

I domn-Magnetic_V ariation. 


wpt-l-Name 

(attribute) 

A unique identifier for the Waypoint. If the Waypoint is an official 
ATC_Named_Waypoint (i.e., a Navigational Aid or other officially 
named point), the official name shall be used; If the Waypoint is defined 
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by the pilot via reference to existing Waypoint(s) (e.g., SPO/30/20 or 
SPO/1 80/EAT/270), then the pilot-entered reference shall be used. 
(“SPO/30/20” and “SPO/180/EAT/270”, respectively, would be the 
names assigned to the example Waypoints.) 

Type: String; 


wpt-l-Type-R17 

(subtype indication) 

The class of Waypoint: is it ATC (officially) defined or just defined 
within this system (by pilot or company)? (This points the way to the 
subtype object classes, which record supplemental information 
appropriate to each class of Waypoint) 


Type: 

Subtype Indication; 

Objects: 

ATCWPT, PCWPT; 


Create_Waypoint 

(process) 

This process allows the creation and deletion of Waypoints. If the 
Waypoint is an official ATC_Named_Waypoint, then the official name 
shall be used. If the Waypoint is defined by the pilot via reference to 
existing Waypoint(s) (e.g., SPO/30/30 or SPO/1 80/E AT/270), then the 
pilot-entered reference shall be used as the name. (“SPO/30/30” and 
“SPO/1 80/EAT/270”, respectively, would be the names assigned to the 
example pilot-defined Waypoints.) Likewise, if the Waypoint is defined 
by the pilot via latitude and longitude coordinates, then these coordinates 
shall be used as the name. Note that pilots may not create ATC_- 
NamedJWaypoints. 
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6.1.54 


WSS--Waypoint_ona_SID_or_STAR 

( regular object class) A Waypoint_ona_SID_or_STAR arises out of the association 
of a particular Waypoint with a particular SS. It captures the information 
relevant to such an association. (The same Waypoint on a different SID or 
STAR may be assigned different data values.) 

“Waypoint_ona_SID_or_STAR” is a somewhat artificial term created for the 
sake of clarity in this analysis; in general usage, the term “Waypoint” may refer 
to both Waypoints and Waypoints on SIDs/STARs (where the meaning is clear 
from the context). For that matter, the term Waypoint may refer to a Waypoint 
on a Flight Plan (see WFP). 

Summary 

Primary Identifier: wss-l-SID-STAR_Name-R08B 

+ wss-l-Waypoint_Name-R08A 


Alias: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 

Attribute: 


Waypoint_Enrollment_onan_SS,Enrollment_onan_SS; 

wss- l-Airspeed_Constraint 

wss- 1 - Airspeed_V alue 

wss- 1 - Altitude_Constraint 

ws s- 1 - Aid tude_V al ue 

wss-l-SID-STAR_Name-R08B 

wss- 1 -Waypoint_Name-R08 A 


Definitions 


wss-l-Airspeed_Constraint 

{attribute) 

This constraint must be continually met during the whole of waypoint 
acqui sition. It applies to the wss- l-Airspeed_Value. 

domn-Leg_Constraint. 


wss-l-Airspeed_Value 

( attribute ) 

This defines the airspeed for the aircraft for the whole of waypoint 
acquisition. The attribute wss-l-Airspeed_Constraint defines what the 
aircra ft must do with this value. 

| domn-Airspeed. 

wss-l-Altitude_Constraint 

(attribute) 

This constraint must be met just by the time the aircraft is actually at the 
wayp oint It applies to the wss-l-Altitude_Value. 

| domn-Point_Constraint. 
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wss-l-Altitude_Value 

(attribute) 

This defines the altitude for the aircraft just when actually at the 
waypoint. The attribute wss- 1- Aititude_Constraint defines what the 
aircra ft must do with this value. 

I domn-Altitude_Above_Mean_Sea_Level. | 


wss-l-SID-STAR_Name-R08B 

(referential attribute) 

The id of the SS which the named Waypoint is on by means of this 
WSS. 

I ss-l-Name. I 


wss-l-Waypoint_Name-R08A 

(referential attribute) 

The id of the Waypoint which is on the named SS by means of this 
WSS __ . 

wpt-l-Name. 
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6.2 Definitions of Common Domains 

Common domains arc created whenever two or more attributes share a common 
domain of values, due to an essential similarity (not a coincidence). This is 
done to follow the guideline, “Document each fact in just one place.” In these 
cases, the group of similar attributes simply reference the common domain 
definition by its name, rather than repeat the shared domain specification. See 
Section 5.6.2 for conventions of common domains. 


domn- Acceleration 

( common do main) 

Type: Numeric; 

Range: from o to 

<> feet per second per second; 
Accuracy: o; 


domn-Aileron_Position 

(t common domain ) 

Type: Numeric; 

Range: from o to o degrees; 

Accuracy: to <> degrees; 


domn>Airspeed 

(i common do main) 

Type: Numeric; 

Range: from <> to <> feet per second; 

Accuracy: o; 


domn-Altitude_Above_Ground_Level 

(i common do main ) 

Type: Numeric; 

Range: from 0 to o feet; 

Accuracy: to <> feet; 


domn-AUitude_Above_Mean_Sea_Level 

(common do main ) 

Type: Numeric; 

Range: from <> to o feet; 

Accuracy: to <> feet; 


domn-Bank_Angle 

(common do main) ______ 

Type: Numeric; 

Range: from o to o degrees; 

Accuracy: to <> degrees; 
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domn-Boolean 
( common do main ) 

Type: Enumeration; 

Values: True, False; 


domn-Column_Position 

(common do main ) 


Type: Numeric; 

Range: from o to o inches; 

Accuracy: to <> inches; 


domn-EIevator_Position 

(common do main) _____ 

Type: Numeric; 

Range: from <> to o degrees; 

Accuracy: to <> degrees; 


domn-Engine_Pressure_Ratio 


Type: 

Numeric; 

Range: 

from o to o; 

Accuracy: 

to <>; 


domn-Engine_RPM 

(common do main ) 

Type: Numeric; 

Range: from o to o [units]; 

Accuracy: to <> [units]; 


domn-Exhaust_Gas_Temperature 

(common do main ) 

Type: Numeric; 

Range: from o to o [units]; 

Accuracy: to <> [units]; 


domn-Engine_Throttle_Position 

(common do main ) 

Type: Numeric; 

Range: from 0 to 100 percent; 

Accuracy: o; 


domn-Flight_Path_Angle 

(common do main ) 

Type: Numeric; 

Range: from o to o degrees; 

Accuracy: to <> degrees; 
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domn-Ground_Track_Angle 

(common do main ) 

Type: Numeric; 

Range: from 0 to 360 degrees; 

Accuracy: to <> degrees; 


domn-Latitude 

(compound c ommon domain) 

domn-Latitude_Degrees 
+ domn-Latitude_Hemisphere. 


domn-Latitude_Degrees 

(common do main ) 

Type: Numeric; 

Range: from 0 to 90 degrees; 

Accuracy: o; 


domn-Latitude_Hemisphere 

(common do main ) 

Type: Enumeration; 

Values: North, South; 


domn-Leg_Constraint 

(common domain) 

A “leg constraint” is a constraint which must be met during the entire 
acquisition of a specified point. The constraint applies to a specified 
value of a named variable. 


Type: 

Enumeration; 

Values: 

Must Stay At, 


Must Stay At or Above, 


Must Stay At or Below, 


domn-Longitude 

(compound c ommon domain) 

domn-Longitude_Degrees 
+ domn-Longitude_Hemisphere. 


domn-Longitude_Degrees 

(common do main ) 

Type: Numeric; 

Range: from 0 to 180 degrees; 

Accuracy: tbd; 


domn-Longitude_Hemisphere 

(common do main ) 

Type: Enumeration; 

Values: East, West; 
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domn-Magnetic_Variation 

(common domain) 

An amount of variation between actual and measured magnetic north; a 
correc tion factor to be applied to compass readings. 

Type: Numeric; 

Range: from -180 to +180 degrees; 

Accuracy: to <> degrees; 


domn-Pitch 

(common do main ) 

Type: Numeric; 

Range: from o to o degrees; 

Accuracy: o; 


domn-Point_Constraint 

(common domain) 


A “point constraint” is a constraint which must be met just by the time 
the aircraft is actually at a specified point It need not be true during the 
acquisition of that point. The constraint applies to a specified value of a 
named variable. 


Type: Enumeration; 

Values: Must be At, Must be At or Above, 

Must be At or Below; 


domn>Radio_Frequency 

(common do main ) 

Type: Numeric; 

Range: from <> to <> MHz; 

Accuracy: to <> MHz; 


domn-RudderJPedal_Position 

(common do main ) 

Type: Numeric; 

Range: from <> to o [units]; 

Accuracy: to <> [units]; 


domn-Rudder_Position 

(common do main ) 

Type: Numeric; 

Range: from o to o degrees; 

Accuracy: to o degrees; 


domn-Stabilizer_Position 

(common do main) 

Type: Numeric; 

Range: from o to o degrees; 

Accuracy: to <> degrees; 
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domn-Temperature 

(i common do main) 


Type: Numeric; 

Range: from o to o [units]; 

Accuracy: to <> [units]; 


domn-Three_D_Position 

( compound common domain) 

A pos ition over the surface of the earth. 

domn-Latitude 
+ domn-Longitude 

+ domn-Altitude_Above_Mean_SeaJLevel. 


domn-Time_of_Day 

(i compound c ommon domain} 

domn-Time_of_Day_Hour 
+ domn-Time_of_Day_Minutes. 


domn-Time_of_Day_Hour 

(i common do main ) 

Type: Integer, 

Range: from 0 to 23; 


domn-Time_of_Day_Minutes 

(i common do main } 

Type: Integer, 

Range: from 0 to 59; 


domn-Two_D_Position 

{ compound common domain ) 

A pos ition on the surface of the earth. 

domn-Latitude 
+ domn-Longitude. 


domn-Wheel_Position 

(i common do main) 

Type: Numeric; 

Range: from o to o degrees; 

Accuracy: to <> degrees; 




domn-X_Offset 

(common domain ) 

This is the east/west component of a distance from a point over the 
surfac e of the earth. A positive value indicates displacement E astward. 

Type: Numeric; 

Range: from o to o feet; 

Accuracy: to <> feet; 


domn-X_Offset_From_Azimuth_Broadeast_Location 

(common domain ) 

This i s an X_Offset from the location of an Azimuth antenna. 
I domn-X_Offset. 


domn-X_Offset_From_Runway_ThreshoId 

(common domain) 

This i s an X_Offset from the threshold of a runway at an airpo rt. 
I domn-X_Offset. ~ ~ 


domn-Y_Offset 

(common domain) 

This is the north/south component of a distance from a point over the 
surface of the earth, A positive value indicates displacement 
North ward. 

Type: Numeric; 

Range: from <> to o feet; 

Accuracy: to <> feet; 


domn-Y_Offset_From_Azimuth_Broadcast_Location 

(common domain) 

This i s a Y_Offset from the location of an Azimuth antenna. 
I domn-Y_Offset. --------- — — 


domn-Y_Offset_From_Runway_Threshold 

(common domain) 

This is a Y_Offset from the threshold of a runway at an airport . 
I domn-YjOffset. 


domn-Yaw_Angle 

(common do main) 

Type: Numeric; 

Range: from o to o degrees; 

Accuracy: to <> degrees; 
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domn-Z_Offset 

( common domain ) 

This is the vertical component of a distance from a point over the surface 
of the earth. A positive value indicates displacement skyward. 

Type: Numeric; 

Range: from O to o feet; 

Accuracy: to <> feet; 


domn-Z_Offset_From_Azimuth_Broadcast_Location 

( common domain ) 

This i s a Z_Offset from the location of an Azimuth antenna. 
I domn-Z_OffseL 


domn - Z_Off set_From_Run way_Th reshol d 

( common domain) 

This i s a Z_Offset from the threshold of a runway at an airport . 
I domn-Z_Offset 
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6.3 System Level Models 

This sub-section documents the system level models (see 5.3.2): the Object 
Class Relationship Model and the Object Class Communication Model. 
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6.3.1 Object Class Relationship Model 

The existence relationships among object classes arc documented via the Object 
Class Relationship Diagram (OCRD) and, where further clarification is needed, 
with textual definitions. In the case of the TSRV flight control system, the 
OCRD suffices to specify die relationships. Figure 6.1 is a fold-out D-size plot 
of the OCRD. 

Please note that a complete understanding of the relationships depicted in the 
OCRD depends on one’s understanding of the graphical conventions employed. 
Refer to 5.6. 
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FOLDOUT FRAME 


Object JJIassJtelationshipJ3iagrafl»; 9 

OCRD 


Note. Please refer to section 5.6. Conventions, for an 
explanation of the significance of various typographical 
features present on this chart. 

Note; Only those object classes related to other object 
classes are shown here. 


WFP4D — Four-0 Jfaypo in t_ 
onaJ r lightJ ) lan * 


8 wfp4dM-FlightJUanJl3flie-R02 
+8 wfp4d-i-Naypoint_Nafne-R02 
+ wfp4d~i-AltitudejtoJ>e_at 
+ wfp4d-l-Planned_Tirae j3f ^Arrival . 


WFP3D — Three-DJrfaypoint_ 
■onaJHightJUan * 

8 wfp3d-l-FlightJ 5 lan_Name-R02 
+8 wfp3d“i*Naypoint_Naflie-R02 
+ wf p2*-i~Alt itudejto Jje_at . 


HFP2D — T wo -D _W ay po in t 
onaj^ight _Plan # 



WFP-~Waypoint_ona_ 
FlightJ^lan * 


8 wfp-i-Flight J’lanjJafne-ROiA 
+8 wfp-i-Waypoint _Name-R0iB 
+ wfp-l-Ordinal_Positionj3nJ 3 lan 
+ wfp-l-Type-RQ2 

+ wf p- i-Methodjo f _Acqu is i t ion-RQ3 . 

* 
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FRAME 



This includes ADIZs and 
CAOIZs and any other 
similar zones. 




















PAR — Pub lis K «d_AiPwa y _pou t e # 


§ par-l-Type-RlO 
+@ par-i-Number. 






AP— Airport # 

6 ap-l-Name 

+ ap-l-Ref erence .Point J.at itude 
+ ap-i-Re f erence J>o int J.ong itude 
+ ap-l-Tower_RadioJ r requency 
* ap-l-ClearanceJtadioJ^equency 
+ ap-l-Ground _Con tr o 1 J>ad io .frequency 
+ ap-l-Autoiwi Jr jnl_Info_SvcJtediaJ : req 
> ap-l-Is jtjJsafcle. 








PAR — Pub 1 i s d_A i r wa y W R 


8 par-i-Type-RlO 
+8 par-i-Number. 

ft 


ft R078“»ayj3ea ft 1 


«SS— Waypoint _ona_ 
SXDj3r_$TAS ft 

8 

wss-l-SID-ST ARJJame-ROBB 

+8 

wss-l-Waypo intJteme-R08A 

+ 

wss-l-Altitude_Value 


wss-l-Alt itude ^Constraint 

+ 

wss-l-AirspeedJ/alue 

+ 

wss-i-AirspeedJConstraint . 

ft 



kyJiejised jn ft 0 <* N 


ft R20B-may_re^ire_thejL»sejDf ft 0 < a N <* i 


MLSSS — MLS J3r*ound_jSy stem ft 


* ftelA-jnayJiave ft 0 <* 


8fnlsgs-l-Airpart_Name-R21 
+ 8mlsgs-l-Runwayjlame-R21 
+ f&lsgs-l-AziiouthJiraadcastJ-ocatian 
+ mlsgs-i-Gnde^athJroadcastJ-ocation 
+ »lsgs-l-FlareJroadcastJ-ocation 
+ mlsgs- l-DME J-ocat ion . 

* 






6.3.2 Object Class Communication Model 

The Object Class Communication Model (OCCM) is specified by one or more 
Object Class Communication Diagrams (OCCDs) which summarize the data and 
events transferred between object classes. In the case of the TSRV flight 
control system, the approach was to develop multiple communication diagrams, 
each focusing on a related subset of the communications in the system. In the 
analysis strategy used (see 5.4), the development of the communication models 
is a simple matter of connecting the inputs and outputs of object classes and 
does not identify new information. In order to maximize the scope of analysis 
on this project, the development of OCCDs was given a low priority, and only 
an example OCCD was generated. The OCCD shown in Figure 6.2 specifies 
the communication among the objects relating to the higher level flight modes. 
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Communication Diagram 1 
"Context for Hlghar Flight Moda* 



communlcataa with additional object 










6.4 Index of Identifiers 

This sub-section is intended to aid in determining where an identifier is defined or referenced. 
Here “identifier” refers to the names of object classes, attributes, derived attributes, events, 
processes and common domains. This index includes entries for every significant piece of an 
identifier. For instance, the attribute “althmc- 1 -Selected_Altitude” appears in the index under 
its full name as well as “l-Selected_Altitude”, “Selected_Altitude” and “Altitude”. 


1 -Airport_Name-R12B-R 14B-R20B 123, 158 , 

1 - Airport_Name-R 1 3 117, 123, 158 
l-Aiiport_Name-R15 100, 158 
l-Airport_Name-R21 107, 158 
l-Airspeed_Constraint 147, 158 
1- Airspeed J^onstraint_for_Wpt_Acq 70, 158 
l-Airspeed_Value 147, 158 
1-Air speed_Value_for_Wpt_Acq 70, 158 
l-Altitude_Constraint 147, 158 
l-Altitude_Constraint_at_Wpt 70, 158 
1 - Altitude_to_be_at 142, 143, 158 
l-Altitude_Value 147, 148, 158 
1 -Altitude_Value_at_Wpt 70, 158 
1 -Automd_Trml_Info_S vc_Radio_Freq 62, 158 
1 -Azimuth_Broadcast_Locadon 107, 158 
l-Broadcast_Frequency 100, 158 
l-Clearance_Radio_Frequency62, 158 
l-Direction_of_Tum 75, 158 
1-DMEJLocation 107, 158 
1-Elevation 110, 126, 158 
l-Flare_Broadcast_Location 107, 108, 158 
1 -Flight_Plan_Name- 1 -R02 70, 71 
l-Flight_Plan_Name-R01 A 71, 72, 139, 142, 143, 
158 

1 -Flight_Plan_Name-R02 72, 142, 143, 158 
1 -Flight J»lan_Name-R03 75, 158 
1-Frequency 110, 158 

1 -Glide_Path_Broadcast_Location 107, 108, 158 
l-Glide_Slope_Angle 100, 158 
l-Ground_Control_Radio_Frequency 62, 158 
l-IAS_Required-R14B 123, 158 
l-Is_it_Usable 62, 158 
1-Latitude 115, 126, 144, 158 
l-Location_Description 144, 158 
1-Longitude 115, 126, 144, 158 
l-Magnetic_Heading 117, 158 
l-Magnetic_Variation 144, 158 
l-Method_of_Acquisition-R03 139, 158 
1 -Missed_Appr_Point 117, 158 
1-Name 62, 63, 65, 69, 75, 84, 110, 113, 114, 
117, 118, 123, 124, 138, 139, 
140, 144, 148, 158 
1-Name-R17 113, 158 
1-Name-R18 103, 158 
1-Number 64, 112, 158 
l-Ordinal_Position_on_Plan 139, 158 
l-Planned_Time_of_Arrival 143, 158 
l-Preferred_Nav_Aid-R05 113, 158 
1 -Preferred_Nav_Aid-R 1 9 103, 158 
l-Primary_Use_Description 113, 158 


1-R02 70, 71 

1-Reference J > oint_Latitude 62, 63, 158 
l-Reference_Point_Longitude 62, 63, 158 
l-Restricted_Area_Name-R16A 115, 158 
l-Route_Name-R09B 138, 158 
l-Route_Name-R10B 64, 158 
l-Runway_Name-R12B-R 14B-R20B 123, 124, 158 
l-Runway_Name-R15 100, 101, 158 
l-Runway_Name-R21 107, 108, 158 
l-Selected_Airspeed 54, 57 
l-Selected_Altitude 58, 61 
l-Selected_Bank_Angle 42, 45, 80, 83 
1 -Selected JFlight_Path_Angle 87, 90, 130, 133 
1 -Selected_Ground_Track_ Angle 91, 94, 130, 133 
l-Selected_Pitch_Angle 42, 45, 80, 83 
l-Selected_Yaw_Angle42, 45, 80, 83 
l-Service_Range 110, 111, 158 
l-Shack_Position 100, 101, 158 
l-SID-STAR_Name-R08B 147, 148, 158 
1-State 57, 61, 90, 94, 99, 129, 137 
1-Threshold 117, 118, 158 
l-Tower_Radio_Frequency 62, 63, 158 
l-Tum_Center Wpt_Name-R04 75, 158 
1-Type 64, 110, 111, 112, 114, 123, 124, 126, 
158 

1-Type-R02 139, 140, 158 
1-Type-R10 158 
1-Type-R17 144, 145, 158 
1-Type-R18 65, 158 
l-Usable_Length 117, 118, 158 
l-Vertex_Number 115, 158 
l-Waypoint_Name-l-R02 70, 7 1 
1 -Waypoint_Name-R0 IB 71, 72, 139, 140, 142, 
143, 158 

l-Waypoint_Name-R02 72, 142, 143, 158 
l-Waypoint_Name-R03 75, 158 
l-Waypoint_Name-R08A 147, 148, 158 
l-Waypoint_Name-R09A 138, 158 
l-Waypoint_Name-R17 64, 65, 158 

1- Wpt_Name-R 1 0A 64, 158 

2- AFD_Designated 47, 79, 160 
2-Altitude_Above_Ground_Level 119 
2-AMtude_Above_Mean_Sea_Level 61, 119 
2-Altitude_E>ifference 58, 61 
2-Angle_of_Attack 119, 120 

2-Armed 128, 134 
2-Attitude_Hold_Engaged 42 
2-Auto_Modes_Engaged 67 
2-Autothrottle_Engaged 48, 56, 128 
2-Bank_Angle 45, 83, 119, 120 
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2-Bank_AngleJRate_of_Change 119, 120 
2-Column_Position 45, 48, 49, 79, 83, 106, 133 
2-Commanded_Aileron_Position 76 
2-Commanded_Airspeed 54, 57, 127, 129 
2-Commanded_Bank_Angle 42, 45, 80, 83, 91, 94, 
95, 99, 104, 106, 130, 133 
2-Commanded_Elevator_Position 76 
2-Commanded_Pitch_AngIe 42, 43, 45, 80, 83, 
104, 106 

2-Commanded_Rudder_Position 76 
2-Commanded_Stabilizer_Position 76 
2-Commanded_Throttle_Position 76 
2-Commanded_Vertical_ Acceleration 58, 61, 87, 
90, 130, 133, 134, 137 

2-Commanded_Yaw_Angle 42, 43, 45, 80, 83, 
104, 106 

2-Current_Engine_Pressure_Ratio 78 
2_Current_Exhaust_Gas_Temperature 78 
2_Current_N 1 _RPM 78 
2_Current_N2_RPM 78 
2-CuiTent_Position 53, 77, 116, 125 
2-Current_Throttie_Position 78 
2-Designated_Default_Mode 48, 49, 74, 160 
2-Distance_to_Tangent 72, 158 
2-Engaged 60, 89, 93, 95, 98, 128, 134, 136 
2-FFD_Designated 47, 79, 160 
2-Flight_Path_Angle 90, 119, 120, 133 
2-Forward_Ftight_Deck_CWS_Engaged 80, 81 
2-Glide_Slope_Engaged 60, 66, 89 
2-Ground_Track_Angle 94, 119, 120, 133 
2-Horizontal_Guidance_Possible 84, 85, 98 
2-Lateral_Deviation 102, 109 
2-Latitude 119, 120 
2-Localizers_Engaged 66, 93 
2-Longitude 119, 120 
2-Pitch_Angle 45, 83, 119, 120 
2-Pitch_Angle_Rate_of_Change 119, 120 
2-Rudder_Pedal_Position 45, 48, 49, 79, 83, 106, 
133 

2-Sideslip_Angle 119, 121 
2-Signal_Strength 102, 109 
2-Time_Guidance_Possible 84, 85, 128 
2-Too_Slow 128 
2-True_Airspeed 57, 119, 121 
2-Velocity_Vector_Hold_Engaged 130 
2-Vertical_Deviation 102, 109 
2-Vertical_Guidance_Possible 84, 85, 136 
2-Wheel_Position 45, 48, 49, 79, 83, 106, 133 
2-Wind_Velocity 119, 121 
2-X_Acceleration 119, 121 
2-Y_Acceleration 119, 121 
2-Yaw_Angle 45, 83, 119, 121 
2- Y aw_Angle_Rate_of_Change 119, 121 

2- Z_Acceleration 119, 121 

3- AFD_Disabled 41, 46, 47, 56, 60, 89, 93, 98, 

128, 136, 160 

3-AFD_Enabled 41, 46, 47, 56, 60, 89, 93, 98, 

128, 136, 160 


3- Airspeed J)ecrement_Request 48, 49, 56 
3-Airspeed_Hold_Mode_Deselect 48, 49 
3-Airspeed JHold_Mode_Request 48, 49, 56 
3-AirspeedJtocrement_Request 48, 49, 56 
3-Altitude_Decrement_Request 48, 50, 60 
3-Altitude_HoId_Mode_Deselect48, 50, 60 
3-Altitude_Hold_Mode_Request 48, 50, 60, 89, 

136 

3-Altitude_Increment_Request 48, 50, 60 
3-Attitude_Hold_Deselect 48, 50, 74, 160 
3-Auto_Modes_Deselect 41, 48, 50 
3-Auto_Modes_Request 41, 48, 50 
3-Auto_Throttle_Deselect 128 
3-Autothrottle_Deselect 48, 50 
3-Default_Mode_Deselect 160 
3-Default_Mode_Request41, 48, 50, 160 
3-Disengage_ACWS 44, 73, 74, 160 
3-Disengage_Auto_Modes40,41,68, 160 
3-Disengage_Default_Mode 40, 41, 74, 160 
3-Disengage_MANEL 73, 74, 105 
3-Disengage_VCWS 40, 41, 132, 160 
3-Disengagement_Criteria_Triggered 58, 60, 61, 
95, 98, 99, 136, 137 
3-Engage_ACWS 44, 73, 74, 160 
3-Engage_Auto_Modes 40, 41, 68, 160 
3-Engage_Default_Mode 40, 41, 74, 160 
3-Engage_MANEL 73, 74, 105, 160 
3-Engage_VCWS 40, 41, 132, 160 
3-Engagement 56 

3-Engagement_Criteria_Satisfied 58, 59, 60, 61, 
95, 98, 99, 134, 136, 137 
3-FFD_Disabled 46, 47, 82, 160 
3-FFD_Enabled 46, 47, 82, 160 
3-Flight_Path_Angle_Decrement_Request 48, 51, 
89 

3-Flight_Path_Angle_Hold_Mode_Deselect 48, 51 
3-Flight_Path_Angle_Hold_Mode_Request 48, 5 1 , 
60, 136 

3-FIight_Path_Angle_Increment_Request 48, 51, 
89 

3-Ground JTrack_AngIe_Decrement JRequest 48 , 
51,93 

3-Ground_Track_Angle_Hold_Mode_Deselect 48, 
51 

3-Ground_Track_Angle_Hold_Mode JRequest 48 , 
51,98 

3-Ground JTrack_Angle_Increment_Request 48, 51, 
93 

3-Horizontal J3uidance_Deselect 48, 51, 98 
3-Horizontal_Guidance_Request 48, 52, 93, 98 
3-Mode_Reversion 56, 73, 74, 95, 96, 98, 134, 

135, 160 

3-Path_Convergence 95, 96, 98, 99, 134, 135, 
136, 137 

3-Path_Divergence 95, 96, 98, 99, 134, 135, 136, 

137 

3-Time_Guidance_Deselect 48, 52, 128 
3-Time J3uidance JRequest 48, 52, 56, 128 
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3-Velocity_Vector_Hold_Dese!ect 41, 48, 52, 160 
3-Velocity_Vector_Hold_Request 41, 48, 52, 160 
3-Vertical_Guidance_Deselect 48, 52, 136 
3-Vertical_Guidance_Request 48, 52, 60, 89, 136 
3-Waypoint_ Acquired 95, 96, 99, 129, 137 
@ ap-l-Name 158 
@ ate war- 1 -Route_Name-R 1 OB 158 
@ atewpt- l-Waypoint_Name-R 1 7 158 
@ cr-l-Name. 158 

@ cwfp-l-FUght_Plan_Name-R02 158 
@ da- 1 -Flight JPlan_Name-R02 158 
@ dmeaa-l-Flight_Plan_Name-R03 158 
@ fp-l-Name. 158 
@ ilsgs-l-Aiiport_Name-R15 158 
@ isn-l-Name-R18 158 
@ mlsgs-l-Airport_Name-R21 158 
@ navaid-l-Name 158 
@ par-l-Type-R10 158 
@ pcwpt-l-Name-R17 158 
@ ra- 1-Name 158 

@ rav- 1 -Restricted_Area_Name-R 1 6 A 158 
@ rw-l-Name 158 
@ ss-l-Name 158 
@ tobj-1 -Latitude 158 
@ wcr-l-Route_Name-R09B 158 
@ wfp-l-Flight_Plan_Name-R01A 158 
@ w^)3d-l-Flight_Plan_Name-R02 158 
@ wQ>4d-l-Flight_Plan_Name-R02 158 
@ wpt-l-Name 158 
@ wss- 1 -SID-ST AR_Name-R08B 158 
AAMC41, 160 

AAMC-- AFD_AFCS_Mode_ControUer 40 
aamc-3-Disengage_Auto_Modes 40, 41, 68, 160 
aamc-3-Disengage_Default_Mode 40, 41, 74, 160 
aamc-3-Disengage_VCWS 40, 41, 132, 160 
aamc-3-Engage_Auto_Modes 40, 41, 68, 160 
aamc-3-Engage_Default_Mcxie 40, 41, 74, 160 
aamc-3-Engage_VCWS 40, 41, 132, 160 
Above_Ground_Level 119, 126, 149 
Above_Mean_Sea_Level 58, 61, 70, 110, 119, 
142, 148, 149, 153 

Acceleration 58, 61, 87, 90, 119, 121, 130, 133, 
134, 137, 149 

Acq 70, 158 

Acquired 95, 96, 99, 129, 137 
Acquisition 72, 75, 158 
Acquisition-R03 139, 158 
Active_Flight_Plan 95, 97, 98, 99, 127, 128, 129, 
134, 135, 136, 137 

Actual 42, 43, 44, 45, 54, 56, 57, 58, 59, 60, 61, 
80, 81, 82, 83, 87, 89, 90, 91, 
93, 94, 130, 131, 132, 133 
Actual_Airspeed 54, 56, 57 
Actual_Altitude 58, 59, 60, 61 
Actual_Flight_Path_Angle 87, 89, 90 
Actual_Ground_Track_Angle 91 , 93, 94 
ACWS 44, 45, 73, 74, 160 
ACWS--Atdtude_Hold_Control_Wheel_ 


Steering_Mode_Controller 42, 45 
acws-l-Selected_Bank_Angle 42, 45 
aews- 1 -Selected_Pitch_Angle 42, 45 
acws-l-Selected_Yaw_Angle 42, 45 
acws-2-Attitude_Hold_Engaged 42 
acws-2-Commanded_Bank_Angle 42, 45 
acws-2-Cominanded_Pitch_Angle 42, 43, 45 
acws-2-Commanded_Yaw_Angle 42, 43, 45 
ADIZs 158 
AFCS 47 

APCS_Enabler46,47 
AFCS_Mode_Controller 40, 41 
AFCSE47, 160 
AFCSE-AFCS_EnabIer 46 
afcse-3-AFD_Disabled 41, 46, 47, 56, 60, 89, 93, 
98, 128, 136, 160 

afcse-3-AFD_Enabled 41, 46, 47, 56, 60, 89, 93, 
98, 128, 136, 160 

afcse-3-FFD_Disabled 46, 47, 82, 160 
afcse-3-FFD_Enabled 46, 47, 82, 160 
AFD 47, 160 

AFD-AflJFlight_Deck_Crew 48 
afd-2-Autothrottle_Engaged 48, 56, 128 
afd-2-Column_Position 45, 48, 49, 106, 133 
afd-2-Designated_Default_Mode 48, 49, 74, 160 
afd-2-Rudder_Pedal_Position 45, 48. 49, 106, 133 
afd-2-Wheel_Position 45, 48, 49, 106, 133 
afd-3-Airspeed_Decrement_Request 48, 49, 56 
afd-3-Airspeed_Hold_Mode_Deselect48, 49 
afd-3-Airspeed_Hold_Mode_Request 48, 49, 56 
afd-3-Airspeed_Increment_Request 48, 49, 56 
afd-3-AltitudeJDecrement_Request 48, 50, 60 
afd-3-Altitude_Hold_Mode_Deselect48, 50, 60 
afd-3-Altitude_Hold_Mode_Request48, 50, 60, 89, 
136 

afd-3-Altitude_Increment_Request48, 50, 60 
afd-3-Attitude_Hold_Deselect48, 50, 74, 160 
afd-3-Auto_Modes_Deselect 41, 48, 50 
afd-3-Auto_Modes_Request 41, 48, 50 
afd-3-Auto_Throttle_Deselect 128 
afd-3-Autothrottle_Deselect 48, 50 
afd-3-Default_Mode_Deselect 160 
afd-3-Default_Mode_Request41, 48, 50, 160 
afd-3-Right_Path_Angle_Decrement_Request 48, 
51,89 

afd-3-Flight_Path Angle_Hold_Mode_Deselect 48, 
51 

afd-3-Flight_Path_Angle_Hold_Mode_Request48, 

51,60,136 

aafd-3-Flight_Rath_Angle_Increment_Request 4 8 , 
51,89 

afd-3-Ground_Track_Angle_Decrement_Request 48, 
51,93 

afd-3-Ground_Track_Angle_Hold_Mode_Deselect 

48,51 

afd-3-Ground_Track_Angle_Hold_Mode_Request 
48, 51, 98 
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afd-3-Ground_Track_Angle_Increment_Request48, 

51,93 

afd-3-Horizontal_Guidance_Deselect 48, 51, 98 
afd-3-Horizontal_Guidance_Request48, 52, 93, 98 
afd-3-Time_Guidance_Dese!ect48, 52, 128 
afd-3-Time_Guidance_Request 48, 52, 56, 128 
afd-3-Velocity_Vector_Hold_Deselect 41, 48, 52, 
160 

afd-3-Velocity_Vector_Hold_Request 41, 48, 52, 
160 

afd-3-Vertical_Guidance_Deselect 48, 52, 136 
afd-3-Vertical_Guidance_Request 48, 52, 60, 89, 
136 

AFD_AFCS_Mode_Controller 40, 41 
AFD_Designated 47, 79, 160 
AFD_Disabled 41, 46, 47, 56, 60, 89, 93, 98, 
128, 136, 160 

AFD_EnabIed 41, 46, 47, 56, 60, 89, 93, 98, 128, 
136, 160 

Aft_Flight_Deck_Crew 48 
Aid 110,158 
Aid-R05 113, 158 
Aid-R19 103, 158 
AIL-Aileron 53 
ail-2-Current_Position 53 
Aileron 53 

Aileron_Position 53, 76, 149 
Aircraft 42, 43, 44, 45, 80, 81, 82, 83, 130, 131, 
132, 133 

Aircraft_Movement 128 
Airport 62, 158 

Airport_Name-R12B-R 14B-R20B 123, 158 
Airport_Name-R13 100, 107, 117, 123, 158 
Airport_Name-R 1 5 100, 158 
Airport_Name-R21 107, 158 
AIRSPDHMC 56, 57 

AIRSPDHMC-Airspeed_Hold_Mode_Controller 

54 

airspdhmc-l-Selected_Airspeed 54, 57 
airspdhmc-l-State 57 

airs|xihmc-2-Comrnanded_Airspeed 54, 57 
Airspeed 54, 55, 56, 57, 70, 119, 121, 127, 129, 
147, 149 

Airspeed_Constraint 147, 158 
Airspeed_Constraint_for_Wpt_Acq70, 158 
Airspeed_Decrement_Request 48, 49, 56 
Airspeed_Hold_Mode_Controller 54, 56, 57 
Airspeed_Hold_Mode_Deselect 48, 49 
Airspeed_Hold_Mode_Request 48, 49, 56 
Airspeed_Increment_Request 48, 49, 56 
Airspeed_to_ActuaI 54, 56, 57 
Airspeed_Value 147, 158 
Airspeed_Value_for_Wpt_Acq 70, 158 
Airway_Route 64, 112, 158 
ALTHMC 60, 61 

ALTHMC--Aldtude_Hold_Mode_Controller 58, 61 
althmc-1 -Selected_Altitude 58, 61 
althmc- 1-State 61 


althmc-2-Altitude_Difference 58, 61 
althmc-2-Commanded_Vertical_Acceleralion 58, 61 
althmc-2-Engaged 89 

althmc-3-Disengagement_Criteria_Triggered 58, 
60,61 

althmc-3-Engagement_Criteria_Satisfied 58, 59, 
60, 61 

Altitude 58, 59, 60, 61 
Altitude_Above_Ground_Level 119, 126, 149 
Altitude_Above_Mean_Sea_Level 58, 61, 70, 110, 
119, 142, 148, 149, 153 
Altitude_Constraint 147, 158 
Altitude_Constraint_at_Wpt 70, 158 
Altitude_Decrement_Request 48, 50, 60 
Altitude_Difference 58, 59, 60, 61 
Altitude_Hold_Mode_Controller 58, 60, 61 
Altitude_Hold_Mode_Deselect 48, 50, 60 
Altitude_Hold_Mode_Request 48, 50, 60, 89, 136 
Altitude_Increment_Request 48, 50, 60 
Altitude_to_Actual 58, 59, 60, 61 
Altitude_to_be_at 142, 143, 158 
Altitude_Value 147, 148, 158 
Altitude_Value_at_Wpt 70, 158 
Angle 42, 43, 45, 80, 83, 87, 88, 89, 90, 91, 92, 
93, 94, 95, 99, 100, 104, 106, 
119, 120, 121, 130, 133, 149, 
150, 151, 154, 158 

Angle_Decrement_Request48, 51, 89, 93 
Angle_Hold_Mode_Controller 87, 89, 90, 91, 93, 
94 

Angle_HoId_Mode_Deseiect 48, 51 
Angle_Hold_Mode_Request 48, 51, 60, 98, 136 
Angle_Increment_Request 48, 51, 89, 93 
Angle_of_Attack 119, 120 
Angle_Rate_of_Change 119, 120, 121 
Angle_to_Actual 87, 90, 91, 94 
AP-Airport 62, 158 

ap-l-Automd_Trml_Mo_Svc_Radio_Freq 62, 158 
ap- 1 -Clearance_Radio_Frequency 62, 158 
ap- 1 -Ground_Control_Radio_Frequency 62, 158 
ap-l-Is_it_Usable62, 158 
ap-l-Name 62, 63, 158 
ap-1 -Reference_Paint_Latitude 62, 63, 158 
ap- 1 -Reference_Point_Longitude 62, 63, 158 
ap-l-Tower_Radio_Frequency 62, 63, 158 
ap-Name 117 
Appr_Point 117, 158 
Arc_Acquisition 75, 158 
Area 114, 158 
Area_Name-R16A 115, 158 
Area_Vertex 115, 158 
ARMED 60, 74, 98, 128, 134, 136 
Arrival 143, 158 
ATC_Named_Waypoint65, 158 
ATC_Waypoint_onan_Airway_Route64, 158 
ATCWAR-ATC_Waypoint_onan_Airway_Route 
64, 158 

atcwar- 1 -Route_Name-R 10B 64, 158 
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ale war- 1 -Wpt_Name-R 1 0 A 64, 158 
ATCWPT— ATC_Named_Waypoint 65, 158 
atcwpt- 1 -T ype-R 1 8 65, 158 
atcwpt- 1 -W aypoint_Name-R 1 7 64, 65, 158 
atcwpt-Name 103 

Attitude_Hold_Comrol_Wheel_S teering_Mode_ 
Controller 42, 44, 45 
Attitude_Hold_Deselect 48, 50, 74, 160 
Attitude_Hold_Engaged 42 
Attitude_of_Aircraft 42, 43, 44, 45, 80, 81, 82, 83 
Attitude_to_Actual 42, 43, 44, 45, 80, 81, 82, 83 
Auto_Modes 40, 41, 68, 160 
Auto_Modes_Controller 67, 68 
Auto_Modes_Deselect 41 , 48, 50 
Auto_Modes_Engaged 67 
Auto_Modes_Request 41, 48, 50 
Auto_Throttle_Deselect 128 
AUTOLAND-Automatic JLanding_Controller 66 
autoland-2-Glide_Slope_Engaged 60, 66, 89 
autoland-2-Localizers_Engaged 66, 93 
AUTOMATIC 41, 50 
Automatic_Landing_Controller 66 
AUTOMC 67, 68, 160 
AUTOMC--Auto_Modes_Controller 67 
automc-2-Auto_Modes_Engaged 67 
automc-2-Engaged 60, 89, 93, 98, 128, 136 
Automd_Trml_Info_Svc_Radio_Freq 62, 158 
Autothrottle_Deselect48, 50 
Autothrottle_Engaged 48, 56, 128 
Azimuth_Broadcast_Location 107, 108, 154, 155, 
158 

Bank.Angle 42, 45, 80, 83, 91, 94, 95, 99, 104, 
106, 119, 120, 130, 133, 149 
Bank_Angle_Rate_of_Change 1 19, 120 
BEHAVIOR 41, 44, 47, 56, 60, 68, 74, 82, 89, 
93, 98, 105, 128, 132, 136 
Board_System 102, 109 

Boolean 42, 48, 66, 67, 79, 81, 85, 95, 130, 134, 
150 

Broadcast.Frequency 100, 158 
Broadcast_Location 107, 108, 154, 155, 158 
CADIZs 158 

CAPTURE 56, 60, 89, 93 
Capture_and_Hold_Selected_Airspeed 54, 55, 56, 
57 

Capture_and_Hold_Selected_Altitude 58, 59, 60, 
61 

Capture_and_Hold_Selected_Flight_Path_Angle 
87, 88, 90 

Capture_and_Hold_Selected_FPA 89 
Capture_and_Hold_Selected_Ground_Track_Angle 
91, 92, 94 

Capture_and_Hold_Selected_GT A 93 
Center_Wpt_Name-R04 75, 158 
Change 119, 120, 121 
Class_Relationship_Diagram 158 
Clearance_Radio_Frequency 62, 158 


Column.Position 45, 48, 49, 79, 83, 106, 133, 
150 

Commanded_Aileron_Position 76 
Commanded_Airspeed 54, 57, 127, 129 
Com manded_B ank_ Angle 42, 45, 80, 83, 91, 94, 
95. 99, 104, 106, 130, 133 
Commanded_Elevator_Position 76 
Commanded_Pitch_ Angle 42, 43, 45, 80, 83, 104, 
106 

Commanded Jtudder_Position 76 
Commanded.Stabihzer.Position 76 
Commanded_Throttle_Position 76 
Commanded_Vertical_Acceleration 58, 61, 87, 90, 

130.133. 134.137 

Commanded. Yaw_Angle 42, 43, 45, 80, 83, 104, 
106 

Communication 160 

Comp_of_Active_Flight_Plan 95, 97, 98, 99, 127, 
128, 129, 134, 135, 136, 137 
Company_Defined_Waypoint 113, 158 
Company.Route 69, 138, 158 
Constrained_Waypoint_ona_Flight_Plan 70, 158 
Constraint 70, 147, 151, 152, 158 
Constraint_at_Wpt 70, 158 
Constraint_for_Wpt_Acq 70, 158 
Control_Inputs 104, 105, 106 
Control_Radio_Frequency 62, 158 
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7.0 SUMMARY, RECOMMENDATIONS, AND CONCLUSIONS 

A definition of a subset of the NASA Transport System Research Vehicle 
(TSRV) flight control system essential requirements was developed using the 
Boeing developed Object Oriented Analysis (OOA) requirements analysis 
methodology. 

The scope of the analysis was limited to the functionality included in the Flight 
Management/Flight Control (FM/FC) computer which hosts the navigation, 
guidance, and flight control software. In terms of depth, a significant portion 
of the essential requirements for the FM/FC software was specified with Data, 
Behavior, and Process Models. Some requirements need further analysis to be 
fully specified. Such requirements were captured via pseudo external object 
classes which serve as placeholders until they can be thoroughly analyzed. 

Follow-on research activities might begin with extending the scope of the 
analysis in terms of both breadth and depth. In regards to depth, it would be 
beneficial to analyze the FM/FC software further to completely ferret out the 
essential requirements relating to portions of the flight control laws, the 
autoland capability, and the sensor data requirements. This process may result 
in the specification of additional object classes and/or modifications of those 
already identified. 

In regards to breadth, additional analysis might address the requirements for the 
on-line simulated airplane capability, the interfaces to other research flight deck 
systems (e.g., the IC, HOLD, and RUN operating system modes), and the 
displays. 

The specification of the display system requirements could be addressed in at 
least two ways. One approach would be to perform an analysis of the Displays 
host computer software functions similar to that of the analysis documented in 
this report. (This could be extended to include the Sperry Color Display 
System if necessary.) The essential functionality could be integrated 
appropriately with the FM/FC functionality specified in this report or as 
extended per the above recommendations. 

Alternatively, the requirements implemented in the displays host could be 
captured in a user interface document where the pilot(s) and the other inflight 
test personnel are viewed as “users” of the system. In this approach, the 
various pilot display formats and real-time data acquisition capabilities are 
considered to be a result of non-essential reformatting of the FM/FC essential 
data and could therefore be appropriately documented in a user interface 
document. 

The goal of another potential follow-on activity might be to formulate a more 
rigorous mapping of the essential system requirements to the existing 
implementation. This might take the form of more detailed Process Model mini- 
specs or merely some degree of cross-referencing of an essential system 
specification to the existing software documentation. Such a mapping might 
provide a better understanding of the current TSRV flight control system, 
however, a design focused specification could hinder innovative architecture 
development of a new system. Also, the complexity of an object-to-code 
mapping may limit its usefulness. 
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A final recommendation for future research addresses the development of 
alternate more advanced software architectures for modem transport flight 
control systems. Architecture trade studies may be conducted on the system 
defined in this report or on any of its enhancements described above. In 
particular, artificial-intelligence based real-time architectures and related 
concepts have shown great potential for flight control application. Studies 
should consider such things as the potential implementation of existing or new 
functions with expert systems, innovative integration of numeric and symbolic 
processing, the real-world technology-based requirements associated with 
failure modes and reliability issues, and the appropriate use of parallel and 
distributed processing. 

In summary, the essential system requirements specification presented here 
offers high visibility of the TSRV flight control system and may be readily 
extended to capture an increased set of existing system functionality and/or may 
be easily modified to accommodate new features, e.g., ones using expert 
system concepts. The Object Oriented Analysis methodology proved to be an 
effective approach to distill the essential requirements of a complex, integrated 
system and the information centered strategy was a useful one for backing out 
the requirements of an existing system. 


176 



8.0 


References 


1 . Frankovich, Major K., Pedersen, Ken, and Bemsteen, Stanley, "Expert 
System Applications to the Cockpit of the ’90s," NAECON ‘85, 
Dayton, OH, May 1985. 

2. Summers, Paul I., "Cockpits for 2010 and Beyond," IEEE AES 
Magazine. February 1986. 

3. Handelman, David A., and Stengel, Robert F., "An Architecture For 
Real-Time Rule-Based Control," Proc. 1987 American Control 
Conference . Minneapolis, MN, June 1987. 

4. Seward, Walter D„ "Task Allocation in a Distributed Computing 
System," Proc. 1987 First Annual Workshop on SOAR . Houston, TX, 
August 1987. 

5. Bruce, Kevin R., "NASA B737 Flight Test Results of Total Energy 
Control System,” Final Report, NASA CR-178285, January 1987. 

6. Goodwin, A.E., "NASA 515 Flight Control System Description," D6- 
34279, Boeing Commercial Airplane Company, September 1976. 

7. "Advanced Transport Operating System Software Upgrade: Flight 
Management/Flight Controls Software Description," Computer Sciences 
Corporation, NASA CR- 18 1936, January 1988. 

8. McMenamin, Stephen M., and Palmer, John F., Essential Systems 
Analysis. Yourdon Press, 1984. 

9. Tockey, Steve, Hoza, Brad, and Cohen, Sam, "Object Oriented 
Analysis: Building on the Structured Techniques," Proc. Software 
Improvement Conference (sponsored by The Educational Foundation of 
the Data Processing Management Association), Washington D.C., 
November 29-30, 1990. 

10. DeMarco, Tom, Structured Analysis and System Specification . 
Yourdon Press, 1979. 

1 1. Ward, Paul T., and Mellor, Stephen J,, Structured Development for 
Real-Time Systems. ” Volumes 1 through 3, Yourdon Press, 1985. 

12. Shlaer, Sally, and Mellor, Stephen J., Object Oriented Analysis: 
Modeling the Worl d m lim, Prentice Hall, 1988. 

13. "Teamwork Environment User's Guide, Release 3.0.3," ENUSE 
3.03, Cadre Technologies Inc., 1988. 

14. Tockey, Steve, “Using Off-the-Shelf CASE Tools to Build Object 
Oriented Analysis Specifications,” Proc. Structured Development 
Forum . San Diego, CA, May 1-3, 1990. 


Q-3 


177 



REPORT DOCUMENTATION PAGE 


Form Approved 
OMB No. 0704-0188 


Public repo rt me burden *o r tms c.cuecticn ef miprmatid* *s :c average * *our oe- response including the time for reviewing instructions, searching existing data sources, 

gather. r.g and maintaining the data needed, ana comp.etmg enc reviewing the obecticn of mformar on. Send comments reqardfng this burden estimate or an, otner aspect of this 
collection of information, nciad.ng suggestions for reducing th»s ourae-' to Washington Heaoauarters Services. Directorate for information Operations and Reports, 1215 Jefferson 
Davis Highway. Suite 12C4 Arlington, y A 222Q2-43G7 and tc me Office O f Management and Budget. Paperwork Reduction Project (07G4-Q1 88). Washington. DC 20503. 

1. AGENCY USE ONLY (Leave blank) 2. RFPOPT DATE 

March 1992 

3. REPORT TYPE AND DATES COVERED 

Contractor Report 

4. TITLE AND SUBTITLE 


5. FUNDING NUMBERS 

NASA TSRV Essential Flight Control System 
Requirements Via Object Oriented Analysis 


C NASl-18027 

6. AUTHOR(S) 


WU 505-66-41-04 

Keith S. Duffy and Bradley J. Hoza 



7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 

Boeing Commercial Airplane Group 
P.O. Box 3707, M/S 6U-ER 
Seattle, WA 98124-2207 

8. PERFORMING ORGANIZATION 
REPORT NUMBER 

NASA CR-189573 

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 

National Aeronautics and Space Administration 
Langley Research Center 
Hampton, VA 23665-5225 

10. SPONSORING /MONITORING 
AGENCY REPORT NUMBER 

11. SUPPLEMENTARY NOTES 

Langley Technical Monitor Richard M. Hueschen 
Langley Contacting Officer’s Technical Representative: 
Final Report - Task 15 

Cary R. Spitzer 


12a. DISTRIBUTION 'AVAILABILITY STATEMENT 


12b. DISTRIBUTION CODE 

Unclassified - Unlimited 
Subject Category 08 




13. ABSTRACT (Maximum 200 words) 


The objective of this work is to analyze the baseline flight control system of the Transport 
Systems Research Vehicle (TSRV) and develop a system specification that offers high 
visibility of the essential system requirements in order to facilitate the future development of 
alternate, more advanced software architectures. The flight control system is defined to be the 
baseline software for the TSRV research flight deck, including all navigation, guidance, and 
control functions, and primary pilot displays. 

The Object Oriented Analysis (OOA) methodology developed by Boeing is used to develop a 
system requirements definition. The scope of the requirements definition contained herein is 
limited to a portion of the Flight Management /Right Control computer functionality. The 
development of a partial system requirements definition is documented, and includes a 
discussion of the tasks required to increase the scope of the requirements definition and 
recommendations for follow-on research. 


14. SUBJECT TERMS 

ATOPS TSRV; Object Oriented Analysis; 
essentia] requirements; advanced architecture 

15. NUMBER OF PAGES 
182 

16. PRICE CODE 

17. SECURITY CLASSIFICATION 

18. SECURITY CLASSIFICATION 

19. SECURITY CLASSIFICATION 

20. LIMITATION OF ABSTRACT 

OF REPORT 

OF THIS PAGE 

OF ABSTRACT 


Unclassified 

Unclassified 




NSN 7540-01-280-5500 


Standard Form 298 (Rev 2-89) 
Prescribed by Afy$i Std Z39-18 
298- K2 


























GENERAL INSTRUCTIONS FOR COMPLETING SF 298 


The Report Documentation Page (RDP) is used in announcing and cataloging reports. It is important 
that this information be consistent with the rest of the report, particularly the cover and title page. 
Instructions for filling in each block of the form follow. It is important to stay within the lines to meet 
optical scanning requirements. 


Block 1. Agency Use Only {Leave blank} . 

Block 2. Report Date . Full publication date 
including day, month, and year, if available (e.g. 1 
Jan 88). Must cite at least the year. 

Block 3. Type of Report and Dates Covered. 


State whether report is interim, final, etc. If 
applicable, enter inclusive report dates (e.g. 10 
Jun87-30Jun88). 

Block 4. Title and Subtitle. A title is taken from 


the part of the report that provides the most 
meaningful and complete information. When a 
report is prepared in more than one volume, 
repeat the primary title, add volume number, and 
include subtitle for the specific volume. On 
classified documents enter the title classification 
in parentheses. 

Block 5. Funding Numbers . To include contract 
and grant numbers; may include program 
element number(s), project number(s), task 
number(s), and work unit number(s). Use the 
following labels: 


Contract 

Grant 

Program 

Element 


Project 

Task 

Work Unit 
Accession No. 


Block 6. Author(s) . Name(s) of person(s) 
responsible for writing the report, performing 
the research, or credited with the content of the 
report. If editor or compiler, this should follow 
the name(s). 

Block 7. Performing Organization Name(s) and 


Address(es) . Self-explanatory. 

Block '8. Performing Organization Report 


Number . Enter the unique alphanumeric report 
number(s) assigned by the organization 
performing the report. 

Block 9. Sponsorino/Monitoring Agency Name(s) 
and Address(es). Self-explanatory. 


Block 10. Sponsorina/Monitorino Aoenc 


Report Number . (If known) 

Block 11. Supplementary Notes. Enter 


information not included elsewhere such as: 
Prepared in cooperation with...; Trans, of...; To be 
published in.... When a report is revised, include 
a statement whether the new report supersedes 
or supplements the older report. 


Block 12a. Distribution/Availabilitv Statement. 


Denotes public availability or limitations. Cite any 
availability to the public. Enter additional 
limitations or special markings in all capitals (e.g. 
NOFORN, REL, ITAR). 


See DoDD 5230.24, "Distribution 
Statements on Technical 
Documents." 

See authorities. 

See Handbook NHB 2200.2. 
Leave blank. 


DOE 

NASA 

NTIS 


Block 12b. Distribution Code. 


NASA - 
NTIS - 


Leave blank. 

Enter DOE distribution categories 
from the Standard Distribution for 
Unclassified Scientific and Technical 
Reports. 

Leave blank. 

Leave blank. 


Block 13. Abstract . Include a brief (Maximum 
200 words) factual summary of the most 
significant information contained in the report. 

Block 14. Subject Terms . Keywords or phrases 
identifying major subjects in the report. 

Block 15. Number of Pages. Enter the total 


number of pages. 

Block 16. Price Code . Enter appropriate price 
code (NTIS only). 

Blocks 17.-19. Security Classifications. Self- 


explanatory. Enter U.S. Security Classification in 
accordance with U.S. Security Regulations (i.e., 
UNCLASSIFIED). If form contains classified 
information, stamp classification on the top and 
bottom of the page. 

Block 20. Limitation of Abstract. This block must 


be completed to assign a limitation to the 
abstract. Enter either UL (unlimited) or SAR (same 
as report). An entry in this block is necessary if 
the abstract is to be limited. If blank, the abstract 
is assumed to be unlimited. 


Standard Form 298 Back (Rev. 2*89) 













